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I.   Introduction 

The  purpose  of  this  paper  is  to  present  a  program 
designed  to  verify  Fortran  syntax.   That  is,  given  a 
line  of  Fortran  coding,  the  syntax  checking  program  will 
analyze  it  for  grammatical  correctness.   However,  before 
the  syntax  checking  program  is  introduced,  the  motivation 
and  considerations  concerning  the  notation,  methods  of 
syntax  specification,  and  practical  implementation  are 
discussed.   Included  are  the  flow  diagrams,  the  syntax 
specification  table,  and  a  listing  of  the  code  for  the 
" syntax  checker . " 

In  this  paper,  a  "syntax  checker"  is  a  program  capable 
of  analyzing  source  statements,  written  in  a  given  program- 
ming language,  for  grammatical  correctness.   However,  on 
the  basis  of  the  techniques  incorporated  in  the  syntax 
checker  presented  below,  this  definition  can  be  made  more 
explicit;   Given  a  set  of  rules  (Syntax  Specification)  for 
forming  allowable  constincts  (syntactic  units),  eventually 
resulting  in  a  statement  (a  line  of  code,  meaningful  in 
terms  of  the  language  being  specified)  of  a  language,  an 
analysis  of  a  source  statement  in  that  language  can  be 
performed  (by  the  syntax  checker)  by  guessing,  or  predicting, 
how  the  statement  is  constructed  and  either  verifying  that 
this  is  the  case  or  backing  up  and  trying  again,  assuming 
some  other  method  of  construction. 

More  specifically  the  syntax  checker  described  here 
is  a  "syntax-directed  source  statement  analyzer."   The 
phrase  "syntax-directed"  refers  to  the  fact  that  the  syntax- 
directed  analyzer  contains  a  relatively  simple  and  direct 
encoding  of  the  syntactic  structure  of  the  language  to  be 
analyzed,  in  the  form  of  a  table,  rather  than  having  the 
syntactic  structure  of  the  language  reflected  in  the  actual 
encoding  of  the  analyzer  algorithm.   The  table  is  comprised 
of  numerical  codes  representing  the  distinct  syntactic  types 
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of  the  language,  and  numerical  operators  representing 
the  relations  .     m   the  various  syntactic  types,  such  as 
concatenation  and  alternativity  [5].   However,  some  advan- 
tage has  been  taken  of  the  structure  of  Fortran  in  order  to 
expedite  execution  of  the  analysis  of  the  source  statements. 
Although,  if  desired,  the  program  could  be  modified  without 
a  great  deal  of  difficulty,  to  be  wholly  syntax-directed. 

The  value  of  syntax  checking  can  be  best  realized  in 
a  time-sharing  system  having  remote  consoles,  where  a  large 
number  of  users  has  access  to  the  central  computing  unit. 
Accordingly  the  motivation  for  on-line  (i.e.,  time - sharing ) , 
interactive  systems  is  to  make  the  computer  "a  more  powerful 
tool,"  and  a  major  factor  of  this  "more  powerful  tool"  should 
be  that  the  computer  is  more  responsive  to  the  user  [3], 
Consequently  to  provide  any  kind  of  convenient,  economical 
service  to  numerous  remote  users,  a  time-sharing  system 
should  allow  program  editing  to  take  place  at  the  same 
level  as  program  construction  [6].   Thus,  if  the  computer 
has  the  facility  to  check  the  syntax  of  the  user's  program 
at  the  time  it  is  being  transcribed,  the  computer  can  aid 
the  user  in  a  most  fundamental  manner.   Hence,  syntax 
checking  at  input  time  becomes  highly  useful  from  the  user's 
standpoint. 

Moreover,  in  a  time-sharing  system  it  is  natural  that 
a  certain  amount  of  real  time  delay  will  exist  for  a  number 
of  programs  before  they  can  be  compiled,  and  eventually 
executed.   When  a  program  is  first  introduced  from  a  remote 
station,  it  is  highly  probable  that  it  contains  errors  in 
coding,  both  grammatical  and  logical.   Since  it  is  unlikely 
that  any  existing  compiler  is  capable  of  actually  correcting 
grammatical  errors,  it  would  be  most  advantageous  to  the 
user  if  he  could  be  informed  of  such  errors  upon  entering 
his  program.   Logical  error  detection  is  of  course  much 
more  difficult,  and  is  usually  left  to  the  programmer  himself, 
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Because  of  a  necessary  wait  for  most  programs  before  they 
are  compiled,  it  is  most  feasible  and  practical  for  the 
user,  and  for  efficient  operation  of  the  time-sharing  system, 
that  the  code  be  checked  for  correct  syntax  as  it  is 
introduced  to  the  system.   In  the  event  that  the  user  does 
have  a  grammatical  error,  this  checking  saves  him  time  which 
would  otherwise  be  wasted,  in  waiting  for  his  program  to  be 
compiled.   Also,  depending  upon  the  comjnunication  facilities 
at  the  user's  console,  he  would  be  allowed  to  correct  the 
code  forthwith  [9]-   Furthermore,  since  immediate  error 
checking  would  insure,  to  a  greater  degree,  that  only  those 
programs  which  are  executable  would  reach  the  compiler,  the 
efficiency  of  the  whole  system  would  thereby  be  increased. 
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II.   Syntax  Specification 

The  two  most  important  and  perplexing  considerations 
arising  in  the  formation  of  the  syntax  checker  were  (l)  de- 
sign of  an  efficient  algorithm  to  perform  the  syntactic 
analysis  and  (2)  development  of  a  practical  specification 
of  the  syntax  of  the  programming  language  being  verified. 
It  will  become  evident  that  the  two  considerations  are 
dependent  upon  each  other. 


1.   Backgroiind 

Syntactic  analysis  has  been  applied  to  most  current 
programming  languages  and  seemingly  more  effectively  to 
others  than  to  Fortran.   Much  work  has  been  done  on  the 
subject  and  the  efforts  have  been  largely  directed  toward 
compiling  and  error  checking.   However,  in  most  cases, 
practical  implementation  has  been  ignored  or  treated  with 
abandon. 

A  most  instructive  and  useful  article  dealing  with 
syntactic  analysis  is  entitled  "Syntax-Directed  Compiling" 
by  Cheatam  and  Sattley  [5].   As  several  of  the  authors' 
propositions  are  realized  in  the  syntax  checker  presented 
in  this  paper,  those  relevant  points  are  discussed.   To 
quote  the  authors,  "Rules  can  be  formulated  to  produce,  or 
recognize,  strings  according  to  the  syntactic  specification 
of  the  language.   In  a  syntax-directed  compiler  it  is  an 
algorithm  which  performs  the  recognition  of  allowable 
input  strings  and  it  does  this  by  using  (an  encodement  of) 
the  Syntax  Specification  as  data.   Hence  this  algorithm 
becomes  an  Analyzer." 

Although  the  Analyzer  is  only  a  part  of  a  syntax- 
directed  compiler,  it  is  the  chief  component  of  a  "syntax 
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checker."   However,  similar  principles  apply,  which  are 
subsequently  explained,  and  are  incorporated  in  the  syntax 
checker. 

With  the  advent  of  Backus  notation  [2],  the  representa- 
tion of  syntax  has  become  convenient  and  comprehensible. 
Consequently  very  few  metalanguage  conventions  are  necessary 
to  complete  the  definitions.   The  formalism  commonly  used 
to  represent  syntax  is  most  similar  to  Backus  Normal  Form. 
For  example,  an  assignment  statement  is  defined  as, 

<assignment>  :=  <variable>  -   <arith  expr> 

where  the  symbol  to  the  left  of  :=  is  called  the  "Defined 
Type"  of  the  definition.   The  portion  to  the  right  of  := 
is  the  "Definiens,"  where  any  sequence  of  type  designators 
appearing  in  a  Definiens  is  called  a  Construction,  and  each 
type  designated  within  the  Construction  is  a  Component  of 
the  Construction.   More  explicitly,   <variable>  and  <arith 
expr>  are  Defined  Types  and  =  is  a  Terminal  Character. 
It  will  be  seen  that  in  the  syntax  table  used  here  the 
Defined  Type  is  given  as  a  "level  number"  which  is  a 
numerical  representation,  and  hence  every  construction  is 
composed  of  level  numbers  and  Terminal  Characters. 

Two  requirements  for  a  useful  Syntax  Specification  are! 

(1)  Any  defined  type  which  occurs  as  a  Component  in 
any  Definiens  must  also  occur  as  the  Defined  Type  of 
some  definition,  and 

(2)  Every  Defined  Type  must  ultimately  be  construct- 
ible  entirely  out  of  Terminal  Characters,   (if  this 
principle  were  not  adhered  to,  it  would  be  impossible 
to  do  any  character  recognition. ) 

These  points  are  highly  practical,  and  become  most  obvious 
when  attempting  to  develop  any  sort  of  analyzer  using  a 
Syntax  Specification. 
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Now  that  formal  specification  has  been  touched  upon, 
the  problem  of  character  recognition  can  be  treated.   If 
either  one  of  the  following  two  conditions  is  satisfied,  an 
occurrence  of  a  given  syntactic  type  has  been  recognized: 

(1)  The  Syntactic  Type  is  a  Terminal  Character, 
and  the  character  at  the  given  position  in  the 
source  string  is  exactly  the  Terminal  Character, 
and 

(2)  The  Syntactic  Type  is  a  Defined  Type,  and 
for  some  one  of  its  Definitions,  concatenated 
occurrences  of  the  Components  of  the  Definiens 
have  already  been  recognized,  in  the  stated  order, 
the  first  of  which  occurs  at  the  given  position. 

In  reality  Terminal  Characters  are  recognized  by  a 
Recognizer  (below  the  Recognizer  is  manifested  by  a  set  of 
functions  called  the  Primitives),  and  it  becomes  the  re- 
sponsibility of  the  Recognizer  to  maintain  the  Input-string 
pointer.   The  fundamental  action  of  the  Recognizer  is  as 
follows:   The  Analyzer  calls  upon  the  Recognizer  to  verify 
if  a  specified  Terminal  Character  occurs  at  a  stated  char- 
acter position  in  the  Input-string.   The  Recognizer  then 
examines  the  character  position  in  the  Input-string.   If 
the  input  character  at  that  position  is  not  the  Terminal 
Character  the  Analyzer  has  asked  for,  the  Recognizer 
reports  failure.   However,  if  the  input  character  is  the 
desired  Terminal  Character,  the  Recognizer  reports  success 
to  the  Analyzer,  and  advances  the  Input-string  pointer  by 
one  character  position. 

Appropriately  it  is  the  job  of  the  Analyzer  to  provide 
Terminal  Characters  for  the  Recognizer  to  verify.   However 
the  Analyzer  is  dependent  upon  the  results  obtained  from 
the  Recognizer.   In  the  syntax  checker  given  here  the  func- 
tion INTAX  is  analogous  to  the  Analyzer  and  its  design  is 
treated  below. 
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2.   Notation 

Thus,  in  considering  the  problem  of  character  recog- 
nition by  the  syntax  checker,  the  need  for  some  systematic 
way  of  denoting  the  syntax  of  the  language  to  be  checked 
becomes  apparent.   Fortunately  in  the  past  few  years  a 
fair  amount  of  study  has  been  devoted  to  formalizing  the 
syntax  of  Fortran.   Thereby  the  burden  of  analyzing  the 
Fortran  language  syntactically  has  been  somewhat  lightened, 


A.   Development 

A  major  difficulty  encountered  in  endeavoring  to 
formalize  Fortran  arose  from  the  fact  that  Fortran  was 
never  explicitly  developed  apart  from  any  system  using 
the  language.   Hence  the  language  can  and  does  vary  greatly 
from  machine  to  machine,  depending  upon  hardware  capabilities 
This  would  seem  to  preclude  any  systematic  and  absolute 
specification  of  Fortran  syntax.   However  some  notable 
attempts  have  been  made  at  formalization.  "Report  on  the 
Algorithmic  Language  Fortran  II"  by  Rabinowitz  [8]  expresses 
Fortran  II  in  a  modified  Backus  Normal  Form.   For  example 
a  "fixed  point  constant"  is  described  in  the  following 
manner: 


• } 


<digit>  :=  o|l|2|3| ...|9| 

<-unsigned  fixed  point  Gonstant>  :=  <digit>  F-,[i;5] 

<sign>  :=  +1  - 

<fixed  point  Gonstant>  :=  <unsigned  fixed  point 

constant>  ]  <sign>  <unsigned  fixed  point 

constant> 
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Symbol         Meaning 

<  a  >  denoting  ct  as  a  syntactic  element  of 

defined  type 

<  a  ^<  ^  >     concatenation,  where  the  construction 

is  a0 

a  I  p  alternativity,  where  the  construction 

is  a  or  3 

:=  "is  defined  as" 

F. [m;n]        quantification  of  the  preceding  syn- 
tactic element 

The  last  symbol  on  the  list  P. [m;n],  was  devised  by 
Rabinowitz  to  denote  quantification.   The  F-,[l;5]  appear- 
ing in  the  example  implies  that  the  syntactic  element  pre- 
ceding the  symbol  may  occur  consecutively  at  least  once 
but  not  more  than  5  times  in  the  element  being  defined. 

As  illustrated  in  the  above  example,  it  is  convenient 
to  enlarge  upon  Backus  notation  when  describing  Fortran. 
Since  Fortran  varies  from  machine  to  machine,  where  certain 
elements  of  the  language  are  largely  a  function  of  the 
machine  word  size  of  the  particular  computer  for  which  the 
language  is  implemented,  meta-operators  are  employed  to 
expedite  the  syntactic  descriptions  for  elements  requiring 
quantification.   Although  the  meta-operator  in  the  above 
example,  which  is  F-,[l;5],  does  not  seem  to  portent  any 
widespread  uses  in  future  descriptions  of  the  language,  it 
certainly  does  emphasize  the  need  and  use  for  such  notation 
in  a  formal  type  description  of  the  language.   The  treat- 
ment of  recursive  properties  of  any  element  presents  no 
problem  when  using  Backus  notation  as  illustrated  by  Rabin- 
owitz.  However  this  does  present  some  difficulty  when  en- 
deavoring to  implement  a  syntax  specification  on  a  computer, 
and  it  becomes  apparent  that  more  efficient  notation  will 
be  needed  to  denote  this  facet  of  the  language. 


The  most  noteworthy  attempt  to  specify  the  syntax  of 
Fortran  appears  to  be  a  table  devised  by  Burkhardt  [4]. 
It  is  from  Burkhardt ' s  table  of  Basic  Fortran  that  the 
syntax  specification  used  here  is  derived.   Burkhardt, 
using  level  numbers  to  represent  each  syntactic  unit, 
along  with  the  additional  aid  of  some  meta-operators  which 
he  developed,  designed  a  table  to  express  the  syntax  of 
Basic  Fortran  [1].   Using  his  notation,  these  excerpts 
are  given  in  order  to  show  specification  of  (l)  the 
"signed  integer  constant,"  which  is  given  as  a  comparison 
to  the  example  above  from  the  work  of  Rabinowitz,  and 
(2)  a  "parameter,"  which  is  an  instructive  example  for  the 
purpose  of  illustrating  the  syntax  specification  used  here  I 


Lev.  No. 

Element 

Definition 

2 

non-zero  digit 

12  2  •••  i 

3 

digit 

_0  2 

4 

integer  letter 

I  J  K  L  M  N 

5 

real  letter 

A  B  ...  H  ^  P 

6 

letter 

5  4 

7 

sign 

+  ^ 

10 

empty 

11 

integer  constant 

^1  3 

12 

signed  integer 

const. 

[10  7]  11 

13 

integer  name 

4  t^   [3  6] 

43 

parameter 

11  13 

where. 

Symbol 

Definition 

Meaning 

terminal  char. 


alternativity 


underlining  denotes 
actual  character 
representation,  not 
level  niimbers 

separated  syntactic 
units  are  used 
exclusively 
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Symbol    Definition       Meaning 


+ 


none      concatenation    connected  syntactic  units 

are  used  in  sequence 

[    ]     metabrackets     combine  several  syntactic 

units  into  a  new  one 

$k        quantification   syntactic  element  following 
(lower  limit)    $k  must  appear  at  least  k 

times,  and  more  if  desired, 
in  that  sequence* 

I'k        quantification   unit  referred  to  after  ^k 
(upper  limit)    may  appear  a  maximum  of  k 

times  in  that  sequence,  or 
less  than  k,  or  not  at  all 

"""the  juxtaposition,  of  placing  together  of  syntactic 
elements  is  not  denoted  by  any  symbol 

* 

for  k=0,  the  unit  referred  to  may  appear  any  number 

of  times,  including  none 

Hence,  $1  3  implies  that  an  integer  constant  (lev.  no. 
11)  must  have  at  lest  one  digit,  but  may  have  many  more. 
The  t4   [3  1 6]  signifies  that  the  unit  referred  to  after  the 
14,  in  this  case  [5|6],  can  only  appear  four  times  at  a 
maximiom,  but  may  not  appear  at  all. 

Thus  with  the  meta-operators,  $k  and  ^k,  the  variable 
length  problem  in  Fortran  can  be  expedited.   Also  from  above, 
the  unit  [3|6]  is  perhaps  convenient  in  this  table  as  that 
unit  occurs  only  once,  but  must  be  redefined  for  actual 
implementation.   So  while  metabrackets  may  be  "level  number 
savers"  they  are  impractical  aside  from  their  appearances 
in  the  table. 


B.   A  practical  syntax  specification 

Therefore  with  such  convenient  notation  and  rather 
powerful  meta-operators  it  is  not  so  formidable  to  derive 
a  table  which  can  actually  be  implemented  on  a  computer, 
and  also  have  the  capability  to  accommodate  additions  and 


-  10 


deletions  in  order  to  comply  with  specifications  of  any 
version  of  Fortran.   Having  studied  the  various  syntax 
specifications  presented  above,  a  table  practical  for 
actual  syntactic  analysis  on  a  computer  has  been  developed 
by  modifying  Burkhardt's  table  and  metalinguistic  notations. 
Examples  are  discussed,  and  the  table  appears  in  Appendix  A. 


B.l.   Level  numbers 

The  concept  of  level  numbers  is  most  important  and 
immediately  suggests  that  such  a  table  can  be  effectively 
stored  in  an  array.   However  it  was  found  that  recursivity 
had  to  be  reformulated  and  also  the  $k  and  fk  meta-operators 
had  to  be  redesigned,  although  their  meanings  are  still  re- 
tained.  The  problem  of  metabrackets  was  easily  disposed  of, 
by  simply  defining  a  new  level  number.   Basic  units  (i.e., 
level  numbers  composed  entirely  of  terminal  characters)  still 
appear  in  the  same  manner,  and  are  appropriately  designated 
in  the  table. 


B.2.   Tree  representation 

At  this  point,  representing  a  syntactical  unit  in  the 
form  of  a  tree,  proved  a  useful  aid  in  deriving  more  readily 
applicable  meta-operators.   Using  tree  diagrams  served  to 
clarify  the  notation  problems  involved  in  developing  a  good 
working  table,  in  conjunction  with  an  efficient  algorithm 
to  perform  syntactic  analysis.   Moreover  the  visualization 
of  the  "trees"  and  the  experimentation  of  taking  all  poss- 
ible paths  suggested  the  requirements  for  the  modified  meta- 
language, to  which  the  "syntactic  analysis"algorithm  could 
be  applied.   In  Burkhardt's  notation  a  tree  for  level  number 
43,  a  parameter,  would  look  like  this: 
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^^  L^\<^1 


where. 

Symbol 
V 

A 


Definition 
I 

juxtaposition 
underlining 


Meaning 

alternativity,  also  referred 
to  as  OR 

concatenation,  also  referred 
to  as  AND 

denoting  terminal  characters 
themselves 


Note  that  in  the  tree  notation  used  here  the  terminal 
nodes  are  identified  by  underlined,  as  well  as  non-underlined, 
characters.   In  the  latter  case,  since  it  would  be  too  cum- 
bersome to  ramify  these  terminal  nodes,  the  numbers  used 
represent  level  numbers  whose  components  are  all  terminal 
characters.   Hence  one  should  refer  to  the  definitions  above. 


B.J).      A   new  metalanguage 

Clearly  there  is  the  need  to  define  each  node  explicitly, 
In  addition  it  would  be  desirable  to  denote  all  branching 
with  a  minimal  number  of  operators,*  and  preferably  be  able 

the  word  operator  is  often  interchanged  with  meta-operator 
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to  express  all  syntactic  units  as  unambiguous  "AND"  and 
"OR"  cases.   But  this  proved  not  to  be  feasible  due  to  the 
variable  length  feature  of  Fortran.   On  the  other  hand 
the  two  operators  $k  and  [k   seemed  to  be  impractical  from 
an  application  standpoint.   After  careful  scrutiny  of 
Burkhardt's  table  it  became  apparent  that  the  $k  operator 
could  be  eliminated  by  rearranging  components  and  using 
the  ik   operator,  since  k  was  always  less  than  or  equal  to 
one  in  Burkhardt's  table.   For  example,  in  level  number  11 
above,  $1  J>   can  be  transformed  to  5   flT  !5  •   As  $1  3 
means  that  level  number  5  must  appear  at  least  once  in 
a  sequence  in  order  to  have  an  integer  constant.   However, 
on  the  CDC  6600,  the  maximum  number  of  digits  (decimal) 
allowed  for  an  integer  constant  is  l8.   Therefore  the  defin- 
ition 3   fl7  3,  replacing  $1  3,  means  that  the  syntactic 
element  represented  by  level  number  3  must  appear  once  in 
the  sequence,  and  may  be  followed  by  no  more  than  17  oc- 
currences of  element  3  ^'^   sequence,  in  order  to  comprise 
an  integer  constant.   The  left  branch  of  the  tree  becomes: 


\\ 


tn  3 
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However  in  some  cases  although  a  minimum  requirement 
for  a  syntactic  unit  was  stipulated  by  the  $k  operator,  no 
maximum  length  for  that  syntactical  unit  is  specified  in 
the  Fortran  language.   In  these  instances,  a  maximum  was 
arbitrarily  designated  to  be  99*   Thus  for  $k  unit,  the 
transformation  would  be:  unit .unit ... k  times... unit 
1^99  unit.   For  the  case,  $0  unit,  the  new  representation 
would  be  ^99  unit,  i.e.,  $0  =  t99-   For  example,  level 
number  17,  which  is  an  "actual  parameter  list,"  originally 
defined  by  Burkhardt  as  51  $0   [,31]  means  element  5I  must 
occur  once,  but  the  syntactic  unit  [,31]  ffisiy  occur  any 
number  of  times  in  sequence  including  zero.   In  the  new 
notation  J>1   $0  [,31]  becomes  3I  ^9  [,31]. 

Thus  having  eliminated  the  $k  operator,  the  set  of 
meta-operators  has  been  reduced  to  three,  AND,  OR,  and 
'l^k.   The  "fk  appears  to  be  most  necessary  as  a  mode  of  ex- 
pressing variable  length  strings.   However  fk  does  not 
operate  in  the  fashion  AND  and  OR  operate;  'fk  operates 
somewhere  in  between  AND  and  OR.   On  one  hand  the  |'k  oper- 
ator implies  alternativity  (OR)  in  the  sense  that  the  unit 
operated  upon  by  the  '\k   may  or  may  not  be  present,  and  at 
the  same  time  it  implies  concatenation  (AND)  by  allowing 
the  possibility  that  the  specified  unit  may  exist  0  to  k 
times  in  succession.   Moreover  the  Ik   operator  can  only 
operate  on  one  operand  (i.e.,  fk  is  a  unary  operator), 
while  AND  and  OR  are  binary  operators . 

In  the  hope  to  clarify  the  modified  metalanguage,  its 
properties  are  symbolically  stated: 

Given  the  syntactic  units,  X,Y,Z,  and  ^,  which  repre- 
sents the  empty  syntactic  unit;  and  the  operators  A, 
V  ,  and  Ik,  the  following  rules  apply: 

1.  XaYaZ=XaYaZ   (order  preserved  under  con- 

catenation) 

2.  XvY=YvX 


14  - 


3.      tk   X   =   a    V    [X]    V    [XaX]   V    [XaXaX] 

V [XaXa  ...k   t  ime  s  .  .  .  AX] 

where  the  new  metalanguage  operators  are: 

Symbol         Meaning 

A  ; none        AND,  concatenation 

V  ;  I  OR,  alternativity 

fk  quantification  (upper  limit),  syntactic 

unit  following  fk  may  appear  0  -  k  times 

In  the  new  notation,  the  above  examples  now  have  the 
following  representation: 

Lev,  no.  Element  Definition 

11  integer  constant  5   ^"17  3 

a  name  part  6\j> 

1J>  integer  name  4  ^^4  a 

where  a  has  a  numerical  value. 

Although  this  modified  notation  may  cause  the  table 
to  expand,  possibly  to  twice  its  original  size,  the  repre- 
sentation of  the  language  is  now  explicit,  and  may  be  ef- 
fectively implemented  on  a  computer.   Of  course  the  set 
of  meta-operators  takes  on  numerical  notation  for  coding 
purposes.   (See  Appendix  B) 
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III.   The  Syntax  Checker  (SYNCH) 

A  syntax  checking  program  has  been  implemented  on  the 
CDC  6600;,  based  upon  a  modification  of  Burkhardt  •  s  descrip- 
tion of  the  syntax  of  Fortran  as  discussed.   Fundamental  in 
the  syntax  checker's  design  (hereafter  referred  to  as  SYNCH 
-  mnemonic  for  SYNtax  CHecker),  is  the  capability  for  adapta- 
tion to  the  6600  time-sharing  system  developed  here  [10]. 

Below  is  a  brief  but  comprehensive  description  of  SYNCH 
elaborating  upon  the  flow  diagram.   This  will  be  followed  by 
a  detailed  explanation  of  some  of  the  components  of  SYNCH 
along  with  illustrative  material. 

SYNCH  is  capable  of  examining  a  line  of  code  to  deter- 
mine if  the  given  code  comprises  a  valid  Fortran  statement. 
The  procedure  is  as  follows j   The  main  program  (EXEC)  obtains 
an  Input-string  from  the  reader  routine  (INREAD)  for  syntactic 
verification.   By  examining  the  first  few  characters  in  the 
Input-string,  the  main  program  establishes  a  goal  for  the 
"top-down"  analyzer  (INTAX).   Then  the  analyzer,  which  is 
syntax  directed,  compares  the  Input-string  against  a  push 
down  list,  which  the  analyzer  has  created  from  the  syntax 
table  stored  in  memory  to  represent  the  specification  of 
the  established  goal.   If,  in  trying  to  verify  the  goal, 
the  analyzer  fails  to  recognize  the  terminal  characters 
in  the  Input-string,  specified  by  the  push  down  list,  the 
given  code  is  syntactically  incorrect  and  an  error  message 
is  given.   In  order  to  simplify  the  checking  certain  environ- 
mental considerations  are  ignored.  For  example,  one  may  in 
Fortran  explicitly  declare  a  variable  to  be  integer  and  use 
this  variable  as  a  do  loop  index;  this  analyzer  does  not 
check  this.  It  also  does  not  check  such  errors  as  duplicate 
or  missing  labels,  or  necessary  declaration  statements. 

1.   Basic  Components  of  SYNCH 

(1)   The  main  program  (EXEC) :   For  a  given  string  (a 
line  of  code  obtained  from  the  reader  routine  INREAD), 
EXEC  on  the  basis  of  the  first  few  characters  determines 
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the  syntactical  unit  to  be  checked  for  in  the  Input-string. 
Since  the  first  few  characters  of  a  Fortran  expression  either 
comprise  a  "keyword"  (e.g.,  COMMON,  FORMAT,  IF,  REAL,  etc.), 
or  alternatively  denote  a  variable  location  in  a  replacement 
statement,  the  syntactic  unit  to  be  verified  can  be  designated 
after  a  "keyword"  analysis.   EXEC,  upon  determining  the  unit 
to  be  checked,  calls  INTAX,  the  table-driven  syntax  analyzer. 
After  the  syntactical  analysis  is  performed  by  INTAX,  EXEC 
receives  the  results,  and  outputs  error  messages. 

(2)  The  syntax  analyzer  (iNTAX):   The  table-driven, 
"top-down,"  syntactic  analyzer  can  only  be  called  by  EXEC, 
which  will  have  specified  the  syntactic  unit  to  be  tested 
for  in  the  given  string.   The  bulk  of  the  syntax  check  is 
performed  by  this  function,  as  opposed  to  EXEC  which  only  does 
a  preliminary  search  in  order  to  establish  a  goal  for  the  "top 
-down"  analysis  by  INTAX.   Then  INTAX  creates  a  push  down  list 
of  the  syntax  of  the  designated  unit  from  the  syntax  table, 
which  is  an  array  whose  elements  comprise  the  syntax  of 
Fortran.  In  the  push  down  list  are  indicators  for  "basic 
character  recognizing"  functions  (i.e.,  functions  which 
recognize  terminal  characters).   In  due  course  every  charac- 
ter in  the  Input-string  is  examined  by  functions  whose 
indicators  appear  in  the  push  down  list.   Depending  upon  the 
presence  or  absence  of  the  terminal  character  specified  for 
recognition  in  the  push  down  list,  INTAX  stacks  and  unstacks 
the  list  with  the  aid  of  special  routines  designed  for  this 
purpose.  Unstacking  is  performed  when  searching  for  a  new  sub- 
goal  or  an  alternative  component.  Stacking  is  effected  when 
pursuing  a  goal.   Eventually  the  push  down  list  is  exhausted 
as  no  more  alternatives  exist,  or  a  sequence  of  successful 
goals  has  been  attained,  and  results  are  reported  to  EXEC. 

(3)  The  primitives!   The  primitives  are  functions  which 
recognize  terminal  characters,  and  are  responsible  for  all 
character  recognition  in  the  syntax  check,  with  the  exception 
of  the  initial  "keyword"  analysis  performed  by  EXEC.  When  an 
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indicator  for  terminal  character  recognition  appears  in  the 
appropriate  place  on  the  push  down  list  created  hy  INTAX,  a 
call  is  set  up  to  the  required  primitive  which  checks  for 
the  specified  terminal  character,  and  then  reports  success 
or  failure  to  INTAX. 

(4)   Input-string  preparation;   INREAD  is  a  function 
which  prepares  a  string  for  syntactic  verification.   For  a 
given  string  INREAD  is  initially  called  by  EXEC,  but  later, 
if  the  original  string  is  exhausted  (in  the  course  of  work 
done  by  INTAX ),  INREAD  may  be  called  through  INTAX  to  prepare 
a  continuation  string  in  the  event  that  one  does  exist. 

SEE  FLOW  DIAGRAM  FOR  SYNCH 

2.   Details  of  Input-string  preparation 

Prior  to  the  explanation  of  the  procedure  for  analyzing 
a  line  of  code,  it  is  necessary  to  be  familiar  with  the  pro- 
duction of  a  string  from  a  line  of  input  code:   In  order  to 
effect  syntactic  analysis  of  a  line  of  code  there  must  be 
some  convenient  way  to  prepare  a  string  for  evaluation  from 
the  original  input  statement.   The  chief  consideration  in 
approaching  this  aspect  of  the  syntax  check  is  the  question 
of  continuation  cards.   If  there  were  no  need  to  limit 
memory  requirements  (i.e.,  amotont  of  computer  memory  words 
for  entire  program),  this  problem  would  require  little 
thought.   However  since  storage  allocation  should  be  kept 
to  a  minimum,  a  little  more  care  must  be  taken  in  determin- 
ing the  method  of  string  preparation  from  input. 

A  string  in  the  sense  used  here  is  a  line  of  Fortran 
code,  exclusive  of  any  label  and  continuation  column,  with 
leading  and  trailing  blanks  removed.   A  given  string  is 
formulated  in  a  buffer  (INS)  composed  of  one  character  (in 
R-format)  per  computer  word.   Associated  with  this  buffer 
is  the  string  pointer  (MARK),  which  can  be  advanced  or  held 
stationary  depending  upon  results  of  the  character  recognition 
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functions  or  addition  of  a  new  string  to  the  buffer.   Be- 
sides the  string  pointer  there  is  another  buffer  pointer 
(LIM)  which  marks  the  end  of  the  buffer. 

A  package  of  three  routines  was  designed  to  handle 
the  formation  of  a  string  from  input,  as  well  as  the  con- 
tinuation cards.   The  function  INTREAD  prepares  a  string 
from  the  input  line  of  a  code  and  enters  the  string  into 
the  buffer  INS,  independent  of  where  control  is  in  the 
program  when  the  string  is  required.   The  two  other  rou- 
tines LOOKIN  and  LOOKEX  are  responsible  for  producing  the 
updated  buffer  (i.e.,  INS  with  a  new  string  incorporated 
into  it)  depending  upon  whether  control  is  in  INTAX  or  the 
main  program  EXEC*   respectively. 

Whenever  EXEC  has  control,  it  is  ready  to  evaluate 
a  new  line  of  code,  and  the  main  concern  is  whether  column 
six,  the  continuation  column,  is  blank.   On  the  other  hand, 
when  INTAX  the  analyzer,  is  in  control,  and  is  looking  for 
a  new  string  (the  string  being  analyzed  has  been  exhausted), 
it  would  want  a  continuation  line  (i.e.,  a  line  where  col- 
xuan   six  is  not  empty)  . 

Because  continuation  cards  may  exist  it  is  necessary 
during  evaluation  to  maintain  previous  strings  and  at  the 
same  time  have  the  next  string  available,  as  well  as  the 
string  currently  being  examined.   The  need  to  retain  pre- 
vious strings  arises  from  the  situation  where  a  continua- 
tion card  is  being  evaluated  and  failure  is  encountered. 
In  this  instance  the  pointer  MARK  must  be  moved  back  to 
the  position  it  was  at  prior  to  the  failure,  and  that  posi- 
tion could  very  likely  be  in  the  previous  line  of  code. 
Hence  a  buffer  of  maximum  200  words  (200  characters)  long 
is  maintained,  and  the  new  string  is  always  added  to  the 
end  of  the  buffer,  thus  preserving  at  least  the  two  pre- 
vious strings.   When  a  new  string  is  to  be  added  to  the 
buffer,  the  current  string  of  characters  in  the  buffer  is 
shifted  left  the  number  of  characters  in  the  new  string,  so 
that  the  characters  which  have  been  in  the  buffer  the 
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longest  are  destroyed,  and  the  new  string  is  added  to  the 
end,  or  the  right  of  the  buffer.   The  buffer  pointer  MARK 
is  then  updated  to  denote  the  beginning  of  the  string  just 
added  to  the  buffer,  and  a  new  LIM  the  end  pointer  is  desig- 
nated . 

Whenever  the  reader  routine  INREAD  is  called,  the  new 
string  for  the  buffer  INS  is  formed  from  a  secondary  buffer, 
and  then  a  new  line  of  code  is  read  from  input  into  the 
secondary  buffer.   Comment  cards  are  ignored.   In  the  event 
that  the  last  card  of  the  program  has  been  detected  (end 
of  file)  a  flag  is  set  (lEND) .   The  secondary  card  buffer 
IBUF  is  eight  words  long  and  must  be  unpacked  in  order  to 
obtain  the  string  for  INS.   Along  with  IBUF  is  a  separate 
word  for  the  continuation  column,  which  can  be  examined 
when  INTAX  is  looking  for  a  new  string  and  the  primary 
buffer  has  been  exhausted.   In  addition  to  the  primary  and 
secondary  string  buffers,  there  are  corresponding  label 
buffers,  which  are  available  for  testing  in  the  main  pro- 
gram EXEC  and  LOOKIN. 

The  differences  between  LOOKIN  and  LOOKEX  are  as  fol- 
lows:  When  a  continuation  card  is  needed  by  INTAX,  INTAX 
calls  LOOKIN.   Then  LOOKIN  checks  the  continuation  word 
(ICON)  first,  and  if  it  is  not  blank,  LOOKIN  calls  INREAD, 
which  enters  the  continuation  string  into  the  buffer  INS. 
If  ICON  is  blank  LOOKIN  returns  control  to  INTAX.   LOOKIN 
also  ensures  that  no  label  exists.   When  the  main  program 
has  control  INREAD  is  called  through  LOOKEX,  which  checks 
only  to  see  that  the  continuation  column  is  empty  in  the 
string  returned  by  INREAD.   The  testing  of  the  corresponding 
label  buffer  (LAB)  if  left  to  another  function  LABTST,  and 
is  called  by  EXEC. 

SEE  FLOW  DIAGRAM  FOR  INREAD 
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3'   Details  of  main  program 

In  SYNCH  the  two  routines  essential  to  the  syntactic 
analysis  are  the  main  program  EXEC  and  INTAX,  the  syntax- 
directed  analyzer.   The  other  routines  perform  the  tasks 
indicated  by  EXEC  and  INTAX,  such  as  character  recognition, 
stacking  and  unstacking  of  push  down  lists,  and  Input-string 
maintenance . 

The  main  program  may  be  thought  of  as  an  executive 
which  not  only  governs  but  expedites  the  work  done  by 
INTAX.   If  INTAX  were  to  explore  every  possible  goal  (syn- 
tactic unit)  the  execution  of  SYNCH  would  require  a  great 
deal  more  time.   Therefore  it  is  advantageous  to  the  ef- 
ficient operation  of  SYNCH  to  call  INTAX  with  a  predeter- 
mined goal  rather  than  to  let  INTAX  determine  the  goal. 
Hence  INTAX  has  been  designed  as  a  "top-down"  type  analyzer, 
where  its  goal  is  preset  by  EXEC.   Thus  EXEC  takes  advantage 
of  the  structure  of  Fortran  in  predetermining  a  goal  for 
INTAX.   In  addition  EXEC  has  the  responsibility  to  verify 
the  label  of  a  statement,  to  check  the  position  of  an 
equal  sign  in  an  arithmetic  replacement  statement,  and  to 
output  error  information.   Control  flows  through  EXEC  as 
follows: 

EXEC  obtains  a  string  for  syntactic  check  from  the 
reader  mechanism  (IPREAD, LOOKEX) ,  along  with  information 
concerning  the  length  of  the  string,  and  the  label  part  of 
the  statement.   Given  this  string,  it  is  the  job  of  EXEC 
to  determine  the  possible  syntactic  structure  of  the  string, 
so  that  the  analyzer  INTAX  can  be  called  with  a  probable 
goal.   Fortunately  Fortran  adapts  readily  to  this  approach, as 
there  are  many  keywords  in  Fortran  serving  to  identify  a 
particular  syntactic  type,  such  as  REAL,  COMMON,  DO  ,  and 
others.   If  a  statement  does  not  begin  with  such  an  identi- 
fying word  it  is  an  arithmetic  replacement  type  statement. 
Hence  after  the  first  character  of  the  string  is  verified 
to  be  alphabetic  (a  non-alphabetic  character  would  be 
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erroneous),  control  is  transferred  to  the  section  of  code 
dealing  with  the  particular  alphabetic.   For  example,  if 
the  first  letter  of  a  statement  is  B,  it  is  possible  that 
the  statement  to  be  evaluated  is  BACKSPACE  i,  where  i  desig- 
nates an  i-o  unit.   On  the  other  hand  B  may  only  signify  a 
variable  in  an  arithmetic  replacement  statement.   In  any 
event  it  is  much  faster  for  EXEC  to  determine  if  the  "key- 
word" BACKSPACE  is  present  than  to  immediately  call  the 
analyzer  INTAX  and  have  that  routine  examine  all  possible 
keywords.   If  the  word  BACKSPACE  cannot  be  recognized, 
EXEC  calls  the  analyzer  with  an  arithmetic  statement  as 
the  goal  to  be  verified .   In  some  cases  where  there  are 
no  keywords  for  a  particular  letter,  control  can  be  immed- 
iately transferred  to  the  part  of  EXEC  dealing  with  arith- 
metic replacement  statements.   However  in  the  keyword  case 
the  actual  syntax  check  can  proceed  much  more  quickly,  since 
the  syntactic  components  for  these  types  of  statements  are 
much  fewer,  and  there  are  fewer  alternative  components, 
than  for  the  replacement  statement. 

In  addition  to  establishing  a  goal  for  the  analyzer, 
EXEC  performs  several  other  necessary  checks  on  the  given 
statement.   While  EXEC  has  control  and  is  establishing  a 
goal,  the  corresponding  label  of  the  given  statement  can 
be  verified:   some  labels  may  be  typographically  incorrect; 
others  omitted  where  required,  and  others  included  when  not 
required.  Another  test  EXEC  performs  is  to  verify  the  place- 
ment of  the  equal  sign  in  a  replacement  statement. 

Once  the  goal  is  established,  and  the  label  verified, 
and  the  equal  sign  placement  is  valid  where  required,  INTAX, 
the  analyzer,  is  called.   The  two  necessary  calling  argu- 
ments given  to  INTAX  are  the  string  pointer  MARK,  which  is 
pointing  to  the  next  character  to  be  verified,  and  the  level 
number  of  the  syntax  table  for  the  established  goal.   EXEC 
regains  control  when  INTAX  has  completed  its  analysis.   If 
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INTAX  reports  failure,  EXEC  outputs  an  appropriate  message. 
Otherwise  control  transfers  to  the  beginning  of  the  program 
and  EXEC  calls  for  another  string  to  examine. 

SEE  FLOW  DIAGRAM  FOR  EXEC 


4.   Details  of  the  primitives 

Before  explaining  the  action  of  the  syntactic  analyzer 
INTAX,  it  is  helpful  to  understand  the  role  of  the  "primi- 
tives" in  SYNCH.   There  are  two  ways  in  which  SYNCH  recog- 
nizes terminal  characters  in  a  given  string:   (l)  when  pre- 
determining a  goal  for  INTAX,  the  function  NOTA  is  called 
to  test  for  certain  keywords,  and  (2)  during  INTAX,  terminal 
character  recognition  is  performed  by  the  primitives.   There 
are  six  different  fuctions  comprising  the  primitives.   The 
six  divisions  arise  from  the  syntax  specification  of  Fortran 
used  in  this  program. 

Each  primitive  is  capable  of  recognizing  a  different 
group  of  characters:   (1)  an  octal  digit,  i.e.,  0-7;  (2)  a 
non-zero  digit,  i.e.,  1-9;  (3)  an  integer  letter,  I-N; 
(4)  a  real  letter,  A-H  or  0-Z;  (5)a  special  character,  blank 
or  +  or  -  or  =  or  ■><■  or  /  or  (  or  )  or  ,  or  .  and  (6)  any  one 
character  designated  in  the  calling  argument.   The  need  for 
this  last  primltve  comes  from  the  fact  that  quite  often  dur- 
ing the  syntax  check,  a  specific  character  must  be  present, 
such  as  (  or  )  or  =,  etc . 

The  primitives  are  called  when  their  representations 
are  encountered  in  INTAX.   As  every  level  number  can  be  ex- 
panded to  components  which  are  terminal  characters,  there 
is  a  special  way  of  designating  these  basic  character  level 
numbers.   The  representations  in  the  syntax  specification 
used  by  INTAX  for  these  special  level  numbers  are  respectively 
(see  above)   (1)  1101,  (2)  1103,  (3)  1104,  (4)  1105,  (5)  1108, 
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and  (6)  10mm  where  mm  is  the  display  code  equivalent  in 
decimal  for  the  special  character  required  to  be  recognized. 
For  example,  1042  calls  for  recognition  of  a  right  paren- 
thesis, where  the  prefix  10  indicates  the  sixth  primitive 
and  k2   is  the  display  code  number  for  a  right  parenthesis. 

The  primitives  are  called  from  INTAX  via  INFUN,   When- 
ever INTAX  wishes  to  verify  a  terminal  character,  (it  has 
a  primitive  representation  on  a  push  down  list),  it  calls 
INFIJN  and  the  primitive  representation  is  one  of  the  calling 
arguments.   The  other  calling  argument  is  the  string  pointer 
MARK.   INFUN  then  directs  a  call  to  the  primitive  corres- 
ponding to  the  given  representation.   For  (6)  which  is 
slightly  different  from  the  other  primitives,  the  last  two 
digits  are  given  as  an  additional  calling  argument  to 
primitive  (6),  which  checks  the  character  in  the  string 
buffer  currently  being  pointed  at  against  the  calling  argu- 
ment . 

Whenever  a  character  is  recognized  by  a  primitive  the 
string  pointer  MARK  is  advanced  one  position,  and  a  new 
MARK  is  returned  as  the  value  of  the  function.   If  the  prim- 
itive cannot  recognize  the  terminal  character  it  is  seeking, 
the  string  pointer  MARK  remains  stationary  and  the  value  of 
the  primitive  is  zero. 


5-   Details  of  the  analyzer 

In  describing  the  construction  of  INTAX,  first  an  in- 
tuitive discussion  will  be  given,  and  then  a  more  technical 
explanation.  Motivating  the  particular  design  of  INTAX  was 
the  creation  and  examination  of  syntax  trees  developed  from 
the  syntax  specification  based  upon  Burkhardt's  table.  Using 
the  set  of  operators  and  operands  explained  above,  an  algo- 
rithm was  formulated  to  traverse  any  tree.  Due  to  the  con- 
textual nature  of  Fortran,  a  main  goal  can  be  readily 
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established.   By  taking  this  "top-down"  approach,  the  ne- 
cessity for  developing  a  tree  embodying  the  whole  Fortran 
language  is  eliminated.   Hence  much  computing  time  can  be 
saved  by  allowing  EXEC  to  determine  the  goal  for  INTAX. 
Consequently  it  becomes  the  job  of  IWAX  to  build  a  tree 
when  given  a  syntactic  element,  and  to  verify  terminal  char- 
acters as  they  appear  in  the  tree. 


5 -A.   A  motivating  example 


To  best  describe  the  algorithm  in  INTAX  the  develop- 
ment of  a  tree  for  a  particular  syntactic  element  will  be 
examined.   As  an  easy  example,  the  syntactic  element  given 
above  will  again  be  used:   the  level  numbers  for  a  "parame- 
ter" are  kj>    :=   ll|l3,   where  the"fully  grown"  tree  is: 


K  ^^'-'^ 
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The  numbers  2,4,5  at  the  terminal  nodes  correspond  to  primi- 
tives for  non-zero  integer,  integer  letter,  and  real  letter, 
respectively.   0  is  the  digit  zero,  and  indicates  that  primi- 
tive (6)  must  be  called.   The  level  number  representation  for 
a  parameter  is  equivalent  to:   <parameter>  :=  <integer  con.>| 
<integer  variable^.   The  string  consisting  of  703  is  to  be 
verified . 

Now  every  branch  ends  in  a  terminal  character.   Hence  it 
is  desirable  to  somehow  recognize  a  particular  terminal  char- 
acter and  then  recognize  its  successor  terminal  character 
until  the  required  syntactic  element  appearing  one  level 
higher  in  the  tree  has  been  recognized.   This  is  done  by 
choosing  a  particular  path  at  the  top  node,  and  exploring  the 
branch.   The  branch  is  explored  according  to  the  path  taken 
at  each  node  dictated  by  the  operators  AND,  OR,  or  fk.   For 
example  at  the  top  node,  let  us  take  the  left  branch  first. 
As  we  travel,  each  step  is  to  be  recorded,  so  we  don't  get 
"lost."  At  each  node  we  ask  is  a  terminal  character  to  be 
recognized,  as  this  is  the  only  way  to  detect  the  end  of  a 
path.   As  a  matter  of  practice  we  will  always  take  the  left 
branch  first  (and  always  grow  our  tree  with  this  convention 
in  mind).   At  11  we  can't  stop,  so  we  save  point  11  and 
move  to  point  3*  repeat  the  previous  step  and  move  to  2; 
this  is  a  terminal  point.   Hence  we  look  for  the  terminal 
character  specified  by  2.   Suppose  the  terminal  character 
is  recognized,  then  we  must  retrace  our  steps  to  see  if  we 
must  also  take  another  path  before  we  are  finished  with  our 
journey.   Hence  back  to  node  3;  at  node  3  one  path  was  suf- 
ficient since  that  node  is  governed  by  an  OR  operator, 
which  dictates  success  at  one  terminal  node  is  sufficient. 
Then  we  move  back  one  more  step  to  node  11;  here  we  must 
take  another  path  as  node  11  is  under  the  AND  operator;  so 
we  move  forward  to  node  3;  we  notice  this  node  is  governed 
by  'flT,  which  means  we  can  travel  the  paths  governed  below 
by  this   operator  back  and  forth  up  to  and  including  17  times. 
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So  on  we  go  again  taking  a  left  from  3  first;  node 
number  2  this  time,  where  failure  is  encountered  since  the 
terminal  character  we  are  trying  to  recognize  is  zero.   We 
go  back  one  stepj  fortunately  we  have  an  OR  operator  which 
says  we  may  try  other  paths  here.   So  we  try  0;  success, 
now  we  go  back  to  node  3,  and  we  have  taken  the  path  from 
node  3  one  out  of  I7  times.   So  we  let  I7  become  16  (i.e., 
k  now  equals  k-1)  and  travel  once  more  just  as  before;  at 
terminal  node  2  we  find  the  character  3;  success  -  repeat 
above;  k  goes  to  k-1  and  we  have  15;  we  set  out  once  again; 
this  time  we  fail  to  recognize  the  required  terminal  char- 
acter, as  there  are  no  more  characters  left  in  the  string 
we  are  looking  at.   Hence  we  go  back  up  the  tree  to  make 
sure  we  have  not  missed  any  paths  which  had  to  be  taken 
(i.e.,  any  nodes  governed  by  AND).   At  node  11  we  are  okay, 
as  11  was  governed  by  OR;  therefore  we  were  successful  on 
that  entire  path.   Now  at  the  top  node  4^,  we  are  also  suc- 
cessful as  43  is  governed  by  OR,  so  we  need  not  travel  any 
other  paths.   However  if  we  had  failed  when  taking  the  left 
path  from  11  originally  we  would  have  been  forced  to  take 
the  right  path  from  4^  as  an  alternative. 


5.B.   Explanation  of  flow  diagram  for  INTAX   (see  flow  dia- 
gram) 

Now  to  explain  the  algorithm  arising  out  of  the  concept 
of  traversing  the  trees  defined  here:   We  always  want  to 
keep  a  record  of  the  path  taken.   Depending  upon  success  or 
failure  at  the  terminal  nodes,  we  are  concerned  with  the 
type  of  branch  at  each  higher  node.   Hence  a  push  down  list 
(LASH)  is  used  to  record  the  path  taken  along  with  the  oper- 
ator at  each  node.   At  any  given  time,  this  push  down  list 
will  represent  the  partial  or  entire  tree  for  the  predeter- 
mined syntactic  goal.   This  list  is  created  from  a  syntax 
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table  whirh  is  stored  as  a  two-dimensional  array  (LIST)  in 
memory.   For  the  above  example  for  syntactic  element  43, 
the  push  down  list  will  at  first  instance  look  like  this: 
13,11,  OR. 

This  operation  constitutes  step  1  on  the  accompanying 
flow  diagram.   Control  then  goes  to  step  2,  where  the  answer 
is  no,  BO  Lhe  level  number  immediately  above  the  last  oper- 
ator on  LASH  is  developed.   In  terms  of  the  above  example, 
the  left  branch  is  taken,  so  we  now  have  I3,  11,  OR,  3, 
^17,  3,  AND.   Once  more  step  2  is  not  satisfied,  so  the  push 
down  list  LASH  becomes  I3,  11,  OR,  3,  tl7,  !> ,    AND,  0,  2, 
OR.   Now  control  transfers  to  step  3*  since  the  last  op- 
erand on  LASH  is  a  primitive  indicator.   At  step  3^  "pop 
terminals"  means  to  remove  0,  2,  OR,  from  LASH,  and  estab- 
lish only  one  of  the  terminals  in  order  to  achieve  success 
on  this  branch.   Only  one  is  needed,  because  the  governing 
operator  is  OR.   Since  we  have  not  reached  the  end  of  the 
string  control  travels  from  step  4  to  step  5'   Since  the 
terminal  function  2  is  successful  in  recognizing  the  re- 
quired character,  control  returns  to  step  2.   Now  the  string 
pointer  MARK  is  pointing  to  zero  in  the  string  buffer  INS, 
and  the  process  is  repeated.   At  step  2  LASH  looks  like  I3, 
11,  OR,  3,  ^YJ .      In  this  case  3,  ^YJ ,    is  the  successor.   The 
node  3  has  been  satisfied.   Since  3  is  not  a  terminal  repre- 
sentative the  process  repeats  itself  until  the  string  is  ex- 
hausted and  there  are  no  more  successor  paths  left  on  LASH. 
(When  zero  is  recognized  in  the  string,  'fl7  becomes  T16 . ) 
In  each  cycle  when  step  2  is  approached  the  source  is  really 
a  sub-goal,  and  is  the  last  operand  on  LASH  before  the  last 
operator. 


5.C.   Implementation 

From  the  flow  diagram  and  the  example  it  can  be  seen 
that  theoretically  INTAX  is  called  again  every  time  a  suc- 
cessor or  alternate  must  be  analyzed,  as  though  the  level 
number  for  the  successor  or  the  alternate  were  the  calling 
argument  to  INTAX.   Thus  INTAX  is  recursive  in  nature.   The 
vector  LASH  is  used  to  stack  all  possible  and/or  necessary 
calling  arguments  to  INTAX,  and  once  a  particular  level 
number  has  been  checked  for,  down  to  its  terminal  compon- 
ents, it  no  longer  appears  on  LASH.   Only  the  level  numbers 
which  have  not  been  expanded  upon,  (i.e.,  those  whose  com- 
ponents have  not  been  fully  verified),  are  found  on  LASH. 
A  successor  level  number  is  sought  whenever  success  has 
been  achieved  on  a  lower  level;  this  operation  is  performed 
by  the  function  NAN.   An  alternate  level  number  is  sought 
whenever  failure  occurs  at  a  lower  level;  this  is  done  by 
the  function  NOR. 

The  push  down  list  LASH  used  in  INTAX  serves  a  dual 
purpose:   (l)  it  is  the  partial  synthesis  of  a  tree  for  a 
designated  syntactic  type,  and  hence  contains  the  necessary 
terminal  characters  if  the  given  string  is  to  be  recog- 
nized, and  (2)  it  supplies  the  machinery  for  recursion,  in 
that  every  time  a  successor  or  alternate  becomes  a  goal,  the 
INTAX  algorithm  commences  once  more. 

Associated  with  the  list  LASH,  are  five  routines, 
(which  together  with  INTAX  really  form  a  specialized  sort  of 
list  processor)  that  facilitate  stacking  (PUSH),  unstack- 
ing  (pop),  searching  for  a  successor  component  (NAN)  or  an 
alternate  component  (NOR),  and  keeping  a  record  of  level 
numbers  which  were  expanded  upon  (LUNA) .   Only  the  search- 
ing functions,  NAN  and  NOR  will  be  discussed  here. 

NAN  is  a  function  which  searches  for  a  successor  on 
the  push  down  list  LASH.   When  a  terminal  character  has  been 
recognized  this  constitutes  success.   At  that  time  INTAX  is 
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concerned  with  evaluating  the  next  required  component  in 
the  list  of  components  on  LASH.   Therefore  NAN  is  called  to 
search  the  push  down  list  for  the  last  level  number  on  LASH 
governed  by  the  operator  AND,  or  the  fk  operator,  which  has 
not  been  previously  built  upon.   When  such  an  element  is 
found,  LASH  is  unstacked  to  remove  all  elements  below  the 
successor.   In  the  case  of  the  ^k  operator,  where  the 
governed  level  number  has  been  built  on,  k  is  reduced  by  one 
and  then  checked  if  k=0 .   If  k  does  equal  zero  the  search 
continues;  if  k  is  unequal  to  zero,  the  level  number  gov- 
erned by  fk  is  established  as  the  successor  component.   In 
the  event  that  no  successor  components  are  left  on  LASH, 
NAN  is  successful,  and  hence,  INTAX  has  achieved  ultimate 
success  for  the  given  string. 

NOR  searches  for  an  alternate  component  on  LASH.   Ini- 
tially a  path  has  been  taken  in  the  syntax  analysis.   How- 
ever at  the  terminal  character  recognition  level,  the  re- 
quired characters  were  not  present  in  the  given  string. 
Now  it  is  the  function  of  NOR  to  search  the  push  down  list 
LASH  for  an  alternate  component  to  build  on.   Since  any 
level  nvimber  in  LASH  which  has  been  built  on  has  been  re- 
corded in  the  vector  MOON,  NOR  can  unstack  LASH  until  it 
finds  a  component  governed  by  the  operator  OR,  which  has 
not  been  built  on,  i.e.,  any  level  number  not  appearing  on 
MOON.   NOR  is  said  to  be  successful  if  it  finds  an  undevel- 
oped alternate  component.   Then  control  can  be  returned  to 
INTAX  and  the  alternate  can  be  established  as  a  new  goal. 
In  the  event  that  no  alternate  component  can  be  found  on 
LASH,  NOR  determines  if  the  governing  operator  may  have  been 
'fk.   If  such  was  the  case,  NOR  can  also  report  success  to 
INTAX,  and  INTAX  can  proceed.   On  the  other  hand,  if  the  fk 
operator  cannot  be  found  on  LASH,  NOR  reports  failure  to 
INTAX,  and  consequently  INTAX  has  failed  to  verify  the  given 
string. 
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The  Syntax  Checker  -  SYNCH 


INREAD 

1. Reads  input 
file  and  pre- 
pares string 
buffer 
2 .Maintains 
secondary- 
buffer 
3 -May  be 
called  by  EXEC 
or  INTAX 
4. Checks  for 
end  of  file 


UOOKlN 


K 


EXECutive  (main  program) 
l.Gets  string  from 
INREAD 

2. Directs  control  on 
basis  of  first  char  in 
string  to  keyword  anal- 
ysis or  arith  stmt 
processing 

^.Determines  syntactic 
unit  to  be  verified  by 
INTAX 

4. Performs  necessary 
work  for  special  cases 
5 .Outputs  errors 


XZ 


s: 


INTAX  (syntax  directed  syntactic 

analyzer) 
1. Checks  for  specified  syntactic 
unit  in  given  string 
2. Creates  and  utilizes  push 
down  list  for  facilitating 
syntactic  check 
3 -Calls  Primitives  when  basic 
char  recognition  is  necessary 
4. Calls  for  continuation  string 
5. Reports  failure  or  success  of 
string  to  agree  with  specified 
syntactic  unit 


^X  »NP0h4 


NOTA- keyword 
recognizer 


MEGAL-equal 
sign   verifier 


LABTST-label 
verifier 


Primitives 

■-1 

1. Determine 
specified  c 

presence  of 
har  in  given 

string 

2. Maintain 
pointer 

input - 

string 

^^ 


NAN-searches  for 
successor 


NOR-searches  for 
alternate 


LUNA-records  sub- 
goals 


PUSH-creates  sub- 
goals 


POP-records  calls 
to  Primitives 
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Input-String  Preparation 


INREAD 


INREAD 

Enter 


test  for  EOF 

flag 


on 


J  RETURN I 


•  off 


secondary  string  buffer 
unpacked  to  temporary 
string  buffer 
IBUF  --MM 
ICON  --  LSI 


secondary  label 
primary  label 
KAB  --  LAB 


^ 


1)  INTAX  calls 

LOOKIN; 

if  ICON  not 
blank, 
LOOKIN 
calls 
INREAD 

2)  EXEC  calls 

LOOKEX; 

LOOKEX  calls 
INREAD 


read  new  line  of  code 

into  secondary  buffer 
set  ICON  and  KAB 


test  for  EOF 


yes 


yes 


no 


set  flag 
lEND  =  1 


test  for 
comment  card 


no 


temporary  string 
buffer  entered  into 
INS:   MM  --  INS 

MARK  updated 
LIM  updated 


RETURN 
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Main  program  -  EXEC 


print 
error 


■^ 


Begin 


col , 


not  empty 


LOOKEX  calls 
INREAD 


EOF  encountered 


STOP 


>^ 


new 
string 


non- 


alpha, 


test  first 
character  of 
string 


alpha. 


NOTA 
checks 
for  a 
given 
keyword 


ii 


MEGAL 
checks 
=  sign 


LABTST 
checks 
label 


failure 


f 


transfer  on  basis  of 
alphabetic  character 
to  test  for  keyword 


and/or  test  for 
arithmetic  replacement 
statement 


statement  label  evaluated 
equal  sign  placement  tested 


goal  specified  for  INTAX  on 
basis  of  results  obtained 
f-rom  NOTA,  or  absence  of 
keyword 


Call  INTAX(  string  ptr.,  goal) 


success 
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INTAX  -  the  syntactic  analyzer 


F 


GOAL 
established 


examine  GOAL 
s  ou  re  e  - 
terminal 
character 
(PUSH) 


yes 


no 


•push  down 
on  GOAL 
save  GOAL 
(PUSH) 


^ 


Enter 

with 

GOAL 

from 

EXEC 


FAIL 


res 


unstack  fori 
successor  I. 
GOAL       ^ 


no 


no 


I  SUCCESS  I 


<r 


string  ptr  advanced - 
unstack  for  successor 
GOAL  (NAN) 


POP  terminals 
and  operator 
(POP) 

3Z 


test  ?or  end 
of  string 


yes 


no 


call  term- 
inal char 
recognizer 
(Prims) 
under  op. 
(INFUN) 


test  for 
continu- 
ation 
line 
(LOOKIN) 


'■es 


fail 


string  ptr 
remains  fixed 
unstack  for 
alternate 
GOAL  (NOR) 


success 
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APPENDIX  A 
Syntax   Specification 


LEVEL 

NUMBER 

NAME 
OPTIONAL  SIGN 

DEFINITION 

1 

tl 

7 

2 

NAME  CHARACTER 

OR 

6 

3 

1> 

DIGIT 

OR 

M2 

0 

\ 

SUBSCRIPT  PART 

AND 

11 

Tl 

5 

5 

SUBSCRIPT  PART 

AND 

■X- 

13 

7  45 

6 

LETTER 

OR 

m4 

M3 

7 

ADD  OPERATOR 

OR 

- 

+ 

8 

INTEGER  STATEMENT 

AND 

16 

= 

22 

9 

FORTRAN  BASIC  CHARACTER 

OR 

3 

6 

M5 

10 

SUBSCRIPT  PART 

AND 

J 

14 

11 

INTEGER  CONSTANT 

AND 

3 

tl7 

3 

12 

SIGNED  INTEGER  CONSTANT 

AND 

1 

11 

13 

INTEGER  NAME 

AND 

M3 

t6 

2 

14 

SUBSCRIPT  EXPRESSION 

OR 

13 

4 

15 

SUBSCRIPT  LIST 

AND 

14 

T2 

10 

16 

INTEGER  VARIABLE 

AND 

13 

tl 

35 

17 

ACTUAL  PARAMETER  LIST 

AND 

31 

t99 

38 

18 

ACTUAL  PARAMETER  PART 

tl 

42 

19 

INTEGER  PRIMARY 

OR 

11 

45 

48 

20 

INTEGER  FACTOR 

AND 

19 

tl 

49 

21 

INTEGER  TERM 

AND 

20 

t99 

50 

22 

INTEGER  EXPRESSION 

AND 

1 

21 

t99  52 

23 

BASIC  REAL  CONSTANT 

OR 

53 

54 

Tl  11 
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24 

REAL  CONSTANT 

AND 

23 

n 

55 

25 

REAL  NAME 

AND 

M4 

t6 

2 

26 

REAL  VARIABLE 

AND 

25 

n 

35 

27 

REAL  PRIMARY 

OR 

24 

56 

89 

28 

REAL  FACTOR 

AND 

27 

n 

61 

29 

REAL  TERM 

AND 

28 

t99 

63 

30 

REAL  EXPRESSION 

AND 

1 

29 

r99 

31 

EXPRESSION 

OR 

22 

30 

32 

VARIABLE 

OR 

16 

26 

33 

ASSIGNMENT  STATEMENT 

OR 

8 

90 

34 

LABEL 

AND 

3 

^4 

3 

35 

VARIABLE  PART 

AND 

( 

15 

) 

36 

LABEL  LIST 

AND 

34 

t99 

65 

37 

COMPUTED  GO  TO 

AND 

( 

36 

) 

38 

PARAMETER  PART 

AND 

J 

31 

39 

IF  STATEMENT 

AND 

67 

34 

65 

40 

NAME 

OR 

13 

25 

41 

CALL  STATEMENT 

AND 

40 

18 

42 

PARAMETER  PART 

AND 

( 

17 

) 

43 

PARAMETER 

OR 

11 

13 

44 

OPTIONAL  PARAMETER 

n 

68 

45 

INTEGER  PRIMARY  PART 

AND 

13 

tl 

57 

46 

UNIT  SPECIFIER 

OR 

11 

13 

47 

VARIABLE  LIST 

AND 

32 

V)? 

84 

48 

INTEGER  EXPRESSION  PART 

AND 

( 

22 

) 

49 

INTEGER  FACTOR  PART 

AND 

* 

* 

19 

50 

INTEGER  TERM  PART 

AND 

51 

20 

64 


66 


65 
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51 

MULT  OPERATOR 

OR 

/ 

* 

52 

INTEGER  EXPRESSION  PART 

AND 

7 

21 

53 

REAL  CONSTANT  PART 

AND 

• 

11 

54 

REAL  CONSTANT  PART 

AND 

11 

. 

55 

EXPONENT  PART 

AND 

E 

12 

56 

REAL  PRIMARY  PART 

AND 

25 

tl 

57 

57 

REAL  PRIMARY  PART 

AND 

( 

58 

) 

58 

REAL  PRIMARY  PART 

OR 

17 

15 

59 

DO  STATEMENT 

AND 

87 

68 

44 

60 

OPTIONAL  OCTAL  STRING 

14 

Ml 

61 

REAL  FACTOR  PART 

AND 

* 

■X- 

62 

62 

REAL  FACTOR  PART 

OR 

27 

19 

63 

REAL  TERM  PART 

AND 

51 

28 

64 

REAL  EXPRESSION  PART 

AND 

7 

29 

65 

LABEL  LIST  PART 

AND 

34 

GG 

COMPUTED  GO  TO  PART 

AND 

13 

6? 

IF  PART 

AND 

31 

) 

68 

PARAMETER  PART 

AND 

43 

69 

DECLARATOR  PART 

AND 

11 

70 

DECLARATOR  PART 

AND 

73 

) 

71 

DECLARATOR  PART 

AND 

40 

70 

72 

DECLARATEON  STATEMENT 

AND 

78 

t99 

77 

73 

DECLARATOR  SUBSCRIPT 

AND 

11 

t2 

69 

74 

DIMENSION  STATEMENT 

AND 

40 

70 

t99 

75 

NAME  LIST  PART 

AND 

J 

40 

76 

NAME  LIST 

AND 

40 

T99 

75 

77 

EQUIVALENCE  PART 

AND 

> 

78 

71 
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78 

EQUIVALENCE  PART 

AND 

ho 

tl 

70 

79 

EQUIVALENCE  PART 

AND 

78 

77 

^99 

77 

80 

EQUIVALENCE  STATEMENT 

AND 

81 

t99 

82 

81 

EQUIVALENCE  PART 

AND 

( 

79 

) 

82 

EQUIVALENCE  PART 

AND 

> 

81 

83 

FUNCTION  DEFINITION 

AND 

40 

85 

= 

31 

84 

VARIABLE  LIST  PART 

AND 

f 

32 

85 

HEADER  PART 

Tl 

86 

86 

HEADER  PART 

AND 

( 

76 

) 

87 

DO  PART 

AND 

54 

13 

= 

43 

88 

SUBPROGRAM  PART 

AND 

40 

tl 

86 

89 

REAL  PRIMARY  PART 

AND 

( 

30 

) 

90 

REAL  STATEMENT 

AND 

26 

= 

30 
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SYNTAX   TABLE    (LIST) 


1 

7 

-10 

2 

3 

6 

0 

3 

1027 

1102 

0 

4 

5 

-10 

11 

-1 

5 

43 

7 

13 

1039 

-1 

6 

1103 

1104 

0 

7 

1037 

1038 

0 

8 

22 

1044 

16 

-1 

9 

1105 

6 

3 

0 

10 

14 

1046 

-1 

11 

3 

-170 

3 

-1 

12 

11 

1 

-1 

13 

2 

-6  0 

1103 

-1 

14 

4 

13 

0 

15 

10 

-20 

14 

-1 

16 

35 

-10 

13 

-1 

17 

38 

-990 

31 

-1 

18 

42 

-10 

19 

46 

45 

11 

0 

20 

49 

-10 

19 

-1 

21 

50 

-990 

20 

-1 

22 

52 

-990 

21 

1 

-1 

23 

11 

-10 

54 

53 

0 

24 

55 

-10 

23 

-1 

25 

2 

-60 

1104 

-1 

26 

35 

-10 

25 

-1 

27 

89 

56 

24 

0 

28 

61 

-10 

27 

-1 

29 

63 

-990 

28 

~1 

30 

64 

-990 

29 

1 

-1 

31 

30 

22 

0 

32 

26 

16 

0 

33 

90 

8 

0 

34 

3 

-40 

3 

-1 

35 

1042 

15 

1041 

-1 

36 

65 

-990 

34 

-1 

37 

66 

1042 

36 

1041 

-1 

38 

31 

1046 

-1 

39 

65 

65 

34 

67 

-1 

40 

25 

13 

0 

41 

18 

40 

-1 

42 

1042 

17 

1041 

-1 

43 

13 

11 

0 

44 

68 

-10 

45 

57 

-10 

13 

-1 

46 

13 

11 

0 

47 

84 

-990 

32 

-1 

48 

1042 

22 

1041 

-1 

49 

19 

1039 

1039 

-1 

50 

20 

51 

-1 

51 

1039 

1040 

0 

52 

21 

7 

-1 

53 

11 

1047 

-1 

54 

1047 

11 

-1 

55 

12 

1005 

-1 

56 

57 

-10 

25 

-1 

57 

1042 

58 

1041 

-1 

58 

15 

17 

0 
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59 

4^ 

68 

87 

-1 

60 

1101 

-40 

61 

62 

1039 

1039 

-1 

62 

19 

27 

0 

63 

28 

51 

-1 

64 

29 

7 

-1 

65 

34 

1046 

-1 

66 

13 

1046 

-1 

67 

1042 

31 

1041 

-1 

66 

43 

1046 

-1 

69 

11 

1046 

-1 

70 

1042 

73 

1041 

-1 

71 

70 

40 

1046 

-1 

72 

77 

-990 

78 

-1 

73 

69 

-20 

11 

-1 

74 

71 

-990 

70 

40 

75 

40 

1046 

-1 

76 

75 

-990 

40 

-1 

77 

78 

1046 

-1 

78 

70 

-10 

40 

-1 

79 

77 

-990 

77 

78 

80 

82 

-990 

81 

-1 

81 

1042 

79 

1041 

-1 

82 

81 

1046 

-1 

83 

31 

1044 

85 

40 

84 

32 

1046 

-1 

85 

86 

-10 

86 

1042 

76 

1041 

-1 

87 

43 

1044 

13 

34 

88 

86 

-10 

40 

-1 

89 

1042 

30 

1041 

-1 

90 

30 

1044 

26 

-1 

-1 


~1 


-1 


-1 


-  ho 


APPENDIX   B 
PROGRAM    SYNCH(  I NPUT,TAPE7.0UTPUT  =  TAPE7 ♦TAPE  1 ♦TAPEAtTAPElO ) 

c   $  »♦«»*«»*«  This  is  exec  ♦»♦»»»»»*♦ 
c 

COMMON/INTRY/INS(200),LIM,IEND.LAB(5)»LSI,NEW 
COMMON/LETHE/LIST( 160,6) ♦LUSH(250) ,N0W(10) .MOON(150) tKON 
COMMON/NFP/INLOG{ 16,2) ♦LTYPE(5.2) 

COMMON/PATCH/ ICON 

REWIND  A 

lEND  =  0 

LIM  =  132 

CALL  SETUP 
C 

5  IF  (LOOKEXtMARK) )   40.10.7 
C 

7  ENDFILE  4 

CALL  EXIT 
C 

10  WRITE(4.1002) 

WRITE (4. 1006)  (LAB (J) . J»l .5 » .LSI » ( INS( J) . J=MARK.LIM ) 
WRITE(4.800) 

GO  TO  5 
C 

40  JUMP  =  INS(MARK) 
C 

WRITE(4.1002) 
1002  FORMAT(//»  THIS  IS  THE  CARD  READ  IN  INREAD*) 

WRITE(4.1006)  (LAB{J)»J»1»5).LSI.<INS<  J),J»MARIC,LIM) 
1006  F0RMAT(1X.72R1/) 
C 

IF  (JUMP  ,LE«  32B)   GO  TO  50 
WRITE(4.801) 
GO  TO  5 
C 

50  MOCK  =  MARK 

GO  TO  (110. 120. 130. 140. 150. 160 .170. 60. 190, 60. 60. 220. 230.60. 60.260. 
X60, 280. 290. 300. 60. 60, 340. 60. 60, 60) ,  jump 

58  MARK  =  MOCK 
C 

60  CONTINUE 

62  IF  (MEGAL(MARK)  .EQ.  0)   GO  TO  540 

63  IF  (LABTST(MU)  ,EQ.  0)   GO  TO  500 

64  CONTINUE 

IF  (INTAX(MARK,33) )   510.520.530 

110  IF  (NOTAC  7HASCENTF    .7  .MARK)  .EO.  0)   GO  TO  112 

111  CALL  LOOKEX(MARK) 

IF  (NOTA(  3HEND        ,3  .MARK)  .EQ.  0)   111.5 

112  IF  (NOTA(  6HASSIGN     .6  .MARK)  ,EQ.  0)   60.480 

120  IF  (NOTA(  9HBACKSPACE  .9  .MARK)  .EQ.  0)   121.420 

121  IF  (NOTA(  9HBL0CKDATA  ,9  .MARK)  .EQ.  0)   60.440 

130  IF  (NOTA(  8HC0NTINUE   .8  .MARK)  .EQ.  0)   131.444 

131  IF  (N0TA(  4HCALL        ,4  .MARK)  .EQ.  0)   GO  TO  132 
NOVA  =41 

GO  TO  422 
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132  IF  (NOTA( 

133  IF  (NOTA( 

134  IF  (NOTA( 
IF  (NOTA( 


7HC0MPLEX  ♦?  tMARK)  .EQ.  0)  GO  TO  134 

8HFUNCTI0N  ,8  ♦MARK)  ,EQ.  0)  460,162 

6HC0MM0N  ♦&  .MARK)  .EQ.  0)  GO  TO  60 

IH/  tl  .MARK)  .EQ.  0)  460.480 


140 


141 


143 

144 
145 
146 

147 


IF  (NOTA(  9HDIMENSI0N  .9  .MARK)  .EG.  0)   GO  TO  141 
NOVA  =  74 
GO  TO  464 

(NOTA(  2HD0 

{LABTST(MU) 

(MEGAL(MARK) 


.2  .MARK)  ,EQ. 
EO.  0)   GO  TO  500 
.EQ.  0)   GO  TO  540 
510.143.530 


IF 

IF 

IF 

IF  (  INTAX(MARK.59) ) 

MARK  =  MOCK 

GO  TO  64 

IF  (NOTA(  4H0ATA        .4  .MARK) 

IF  (NOTA(  7hDEC0DE(    .7  .MARK) 

IF  (NOTA( 10hD0UBLEPREC.10.MARK) 

IF  (NOTA(  5HISI0N      .5  .MARK) 

IF  {NOTA(  6H00UBLE     .6  .MARK) 


0)   GO  TO  144 


.EQ. 
.EO. 
.EQ. 
.EO. 
.EQ. 


0) 
0) 

0) 
0) 
0) 


145.480 
146.490 
60  TO  147 
520.462 

60.133 


150  IF  (NOTA(lOHEQUIVALENC.lO.MARK)  .EQ.  0)   GO  TO  151 

.1  .MARK)  .EQ.  0)   GO  TO  520 


151 
152 

153 


IF  (NOTAf 
NOVA  =  80 
GO  TO  464 
IF  (NOTA( 
IF  (NOTA( 
IF  (NOTA( 
NOVA  =  76 
GO  TO  464 


IHE 


7HENDFILE 

3HEND 

8HEXTERNAL 


.7 

♦  3 
.8 


.MARK) 
♦MARK) 
.MARK) 


.EQ. 
.EQ. 
.EQ. 


0) 
0) 
0) 


152.420 
153.440 
GO  TO  154 


154  IF  (NOTA(  7hENC0DE( 


♦7  .MARK)  .EO.  0)   60*490 


160 
161 
162 

163 


164 

165 
166 
167 


IF  (NOTA( 
IF  (NOTA( 
NOVA  =  88 
GO  TO  464 
IF  (NOTA( 
IF  (NOTA( 


7hF0RMAT(    .7  .MARK)  .EQ.  0) 
8HFUNCTI0N   .8  ♦MARK)  .EQ.  0) 


7HF0RTRAN    *!     ♦MARK)  .EQ.  0) 
2HII  *2     ♦MARK)  .NE.  0) 

CALL  N0TA(2HIV.2.MARK) 

DO  165   JJ=1.5 

IF  (NOTA{LTyPE( JJ.l) .LTYPEf JJ.2) .MARK) 

CONTINUE 

IF  (N0TA(  8HFUNCTI0N   .8  ♦MARK)  .EQ.  0) 

IF  (NOTA( lOHSUBROUTINE.lO.MARK)  .EQ.  0) 

NOVA  =  88 

GO  TO  464 


161 ^490 
GO  TO  163 


GO 
GO 


TO 
TO 


60 
164 


NE.  0)   GO  TO  166 

167.162 
GO  TO  490 


170  IF  (NOTA(  5HGOT0(       .5  .MARK)  .EQ.  0)   GO  TO  174 
MARK  =  MARK  -  1 

NOVA  =  37 

171  IF  (MEGAL(MARK)  .NE.  0)   GO  TO  58 
IF  (LABTST(MU))   173.500.172 

172  WRITE(4.808) 

173  IF  { INTAX(MARK,NOVA) )   510.520.530 

174  IF  (NOTA(  4HG0T0        .4  .MARK)  .EQ.  0)   GO  TO  60 
NOVA  =  34 

GO  TO  171 


190  IF  {NOTA(  3HIF( 


♦3  .MARK)  .NE.  0)   GO  TO  400 


42 


IF  (NOTA(  7HINTEGER  .7  »MARK)  .EQ.  0)  60*133 

220  IF  (NOTA(  7HL0GICAL  ,7  .MARK)  .EO.  0)  60»133 

230  IF  (NOTA(  7HMACHINE  »7  tMARK)  .EQ.  0)  60»111 

260  IF  (NOTA(  ShPRINT  .5  .MARK)  .NE.  0)  GO  TO  480 
IF  (NOTA(  5HPAUSE  *5    .MARK)  .EQ.  0)  60  TO  261 

262  NOVA  =  60 
60  TO  422 

261  IF  (NOTA(  5HPUNCH  »5  .MARK)  .NE.  0)  60  TO  480 
IF  {NOTA(  7HPR0GRAM  ^7  ♦MARK)  .EO.  0)  60»480 

280  IF  (NOTA(  6HRETURN  .6  .MARK)  .NE.  0)  GO  TO  444 

IF  (NOTA(  6HREWIND  .6  .MARK)  .NE.  0)  GO  TO  420 

IF  {NOTA(  4HREAD  »4  »MARIC)  .NE.  0)  GO  TO  480 

IF  (NOTAC  4HREAL  .4  tMARK)  .EQ.  0)  60»133 

290  IF  (NOTAdOHSUBROUTINE.lOtMARK)  .EQ.  0)  GO  TO  291 
NOVA  =  88 

GO  TO  464 

291  IF  (NOTA{  4HST0P  .4  .MARK)  .EQ.  0)  292*262 

292  IF  (NOTA(  7HSEGMENT  .7  »MARK)  .EQ.  0)  293*480 

293  IF  (NOTAdOHSENSELIGHT.lOtMARK)  .EQ.  0)  60»490 

300  IF  (NOTA(  4HTYPE  .4  .MARK)  .EQ.  0)  GO  TO  60 
DO  301   JJ=1»5 

IF  (N0TA(LTYPE( JJ»1) .LTYPEC JJ.2)*MARK)  .NE.  0)   GO  TO  462 

301  CONTINUE 
GO  TO  58 

340  IF  (NOTA(  5HWRITE  *5    tMARK)  .EQ.  0)  60»480 


400  CONTINUE 

IF  (NOTA(10hSENSELIGHT»10»MARK)  .EQ.  0)   GO  TO  401 
NOVA  =  96 
60  TO  422 

401  IF  (NOTA(10hSENSESWITC»10»MARK)  .EQ.  0)   60  TO  402 
IF  (N0TA(1HH»1»MARK)  .EO.  0)   GO  TO  520 

60  TO  490 

402  IF  (N0TA(7HENDFILE.7»MARK)  .EQ.  0)   60  TO  4O4 

403  CONTINUE 
60  TO  490 

404  IF  (N0TA(4HE0F.»4.MARK)  .EQ.  0)   405*403 

405  MARK  =  MARK  -  1 
NOVA  =  39 

GO  TO  422 

420  NOVA  =  46 

422  IF  (ME6AL(MARK)  .NE.  0)   GO  TO  58 
424  IF  (LABTST(MU)  .FQ.  0)   GO  TO  500 
IF  (INTAX(MARK*NOVA) )   510.520*530 

440  IF  (LABTST(MU)  .NE.  -1)   500.442 
442  IF  (MEGALCMARK)  .NE.  0)   58*530 
444  IF  (LABTST(MU)  .EQ.  0)   500.442 
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460     IF    (MEGAL(MARK)     .NE.    0)       GO    TO    58 
462    NOVA    =    72 

464     IF     (LABTSKMU)     .NE.    -1)       GO    TO    500 
IF     (  INTAX(MARIC»NOVA)  )       510. 520*530 

480    IF     (MEGAL(MOCK)     .LE.     10)       GO    TO    58 
490     IF     (LABTST(MU)     .EO.    0)       GO    TO    500 
492     IF     (ICON    .EQ.     55B)       GO    TO    5 

CALL    LOOICIN(MARK) 

GO  TO  492 
C 

c 

C   BAD  LABEL 
C 

500  WRITE(4.802) 

WRITE(4»803     )     (  LAB  (  J  )  .  J»l  »5  )  .LSI  ♦  (  INS(  J)  t  J  =  MOCIC.LIM  ) 

GO  TO  5 
C 
C   NO  CONTINUATION  CARD 

C 

510  WRITE(4»804) 

WRITE(4»803  )  ( LAB ( J) ♦ J«l .5 ) .LSI , (INS( J ) ♦ J^MOCK.LIM) 
IF  (LSI  .EG.  55B)   5»10 
C 

C   LOUSY  SYNTAX 
C 

520  WRITE(4»805) 

WRITE(4»803  )  ( LAB ( J ) . J=l »5 ) .LSI ♦ ( INS( J) ♦ J«MOCK ,LIM) 
GO  TO  5 
C 

530  IF  (MARK  .GE.  LIM)   5.520 
C 

C   NO  EQUAL  SIGN 
C 

540  WRITE(4.806) 

WRITE(4.803  )  ( LAB ( J ) . J=l .5 ) .LSI . ( INS( J ) ♦ J=MOCK.LIM) 
GO  TO  5 


C 


800  FORMAT(*  COL  6  NOT  EMPTY  WHEN  LOOKING  FOR  NEW  STRING*) 

801  FORMAT(»  FIRST  COL  OF  STRING  INCORRECT  ♦) 

802  FORMAT(»  LABEL  NOT  SUITABLE  FOR  STMT*) 

803  F0RMAT(6X.72R1.////) 

804  FORMAT(*  CONT  CARD  NOT  FOUND  WHEN  CALLED  FOR*) 

805  FORMAT(*  INCORRECT  SYNTAX*) 

806  FORMAT(*    EQUAL  SIGN  MISSING*) 

808  FORMATC*    SERIOUSLY.  LABELING  A  GO  TO  STMT..*) 

END 

SUBROUTINE  SETUP 

COMMON/LETHE/LIST (160.6) .LUSH (250) .NOW( 10) ♦MOON( 150) .KON 
COMMON /NFP/ I NLOG( 16.2) .LTYPE(5.2 ) 
DIMENSION  KARD(IO) 
CALL  ZERO(LIST.1200) 
MOT  «  0 
99  FORMAT ( IHl) 

READ( 10.101 )  ( ( INL0G(J.JJ).JJ=1.2) »J=1.16) 
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READ( 10,101)  ( (LTYPE(J»JJ) . JJ=1 .2 ) ♦ J=l tS ) 

101  FORMAT(A10,2X»I2) 

10  READ(IO.IOO)  LNO.(KARD( J) ♦J=l,5) 
100  FORMAT(6I10) 

IF  (ENDFILE  10)   77,20 
20  DO  30   J=l»5 

K  =  J 

IF  (KARO(J)  .EQ.  0  .AND.  IS  IGN  ( 1  .ICARD(  J )  )  .LT.  0)   GO  TO  35 

30  LIST(LN0»J+1)  =  KARDCJ) 

K  -  K  +  1 
35  IC  »  K  -  1 

LISTtLNO.l)  =  K 

IF  (LNO  .GT,  MOT)   MOT  =  LNO 

GO  TO  10 
77  PRINT  99 

REWIND  10 

DO  40   J  eltMOT 

IF  (LIST(J»1)  .EQ.  0)   GO  TO  40 

NOE  »  LIST(J»1)  +  1 

PRINT  102»J.(LIST(J,K),K=1,NOE) 

102  FORMAT(»  LEV  NO  IS»I4»    NOE  I S»I4 tS ( 2X, 1 10 ) ) 
WRITE( 10,166 )J.( LIST ( J. IJM) ,IJM«2»N0E) 

166  FORMAT(7I10) 
40  CONTINUE 
PRINT  99 
ENDFILE  10 
RETURN 
END 

FUNCTION  NOR(KPU) 
C0MMON/LETHE/LIST(160,6)  »LUSH(250)  »NOW(  10)  ,MOON(  150)  .ICON 

LN  «  KPU 

IF  (LUSH(KPU)  .NE.  -1)   GO  TO  10 
5  IF  (LUNA(LUSH(KPU-1)+1000»(KPU-1) )  .NE.  0)   KPU  «  KPU  -  2 
10  IF  (LUSH(KPU)  .NE.  0)   GO  TO  20 

12  KPU  =  KPU  -  1 

13  IF  {LUNA(LUSH(KPU)+1000*(KPU) )  .EQ.  1)   GO  TO  15 

KPU  =  KPU  +  1 
LUSH (KPU)  =  0 
NOR  =  1 
RETURN 

15  KPU  =  KPU  -  1 

IF  (KPU  .EQ.  0)   GO  TO  30 
IF  (LUSH(KPU))   20,12,13 

20  IF  (LUSH(KPU)  .GE.  -1)   GO  TO  25 

IF  (LUNA(LUSH(KPU-1)+1000»(KPU-1 ) )  .EQ.  0)   GO  TO  25 
LUSH (KPU)  =  0 
NOR  «  NAN (KPU) 
RETURN 

25  KPU  =  KPU  -  1 

IF  (KPU  .GT.  1 )   GO  TO  10 
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c 

c 


c 
c 


c 
c 


30  KPU  =0 

35  KPU  =  KPU  +  1 

IF  (KPU  .EO.  LN)   GO  TO  77 

IF  (LUSH(KPU)  .GT.  0)   GO  TO  35 

IF  (LU5H(KPU)  .EO.  -1)   GO  TO  77 
KPU  ■=  KPU  -  2 
NOR  »  1 
RETURN 
77  KPU  =  0 
NOR  =  0 
RETURN 

END 

FUNCTION  NAN(KPU) 

C0MMON/LETHE/LIST< 160 »6) t LUSH (250) .NOW (10) .MOON( 150) *KOH 

COMMON/ I NTRY/ INS (200) tL IM, I END.LAB ( 5 ) »LSI »NEW 

10   IF  (LUSH(KPU)  .LT,  0)   GO  TO  20 

12  KPU  '    KPU  -  1 

IF  (KPU  .GT.  1)   GO  TO  10 

15  NAN  =  0 
RETURN 

20  IF  (LUSH(KPU)  .LT.  -1)   GO  TO  40 
KPU  =«  KPU  -  1 

25  IF  (LUNA(LUSH(KPU)+1000»(KPU) )  .EQ.  1)   GO  TO  30 

KPU  =  KPU  +  1 
LUSH(KPU)  =  -1 
NAN  =  1 
RETURN 

30  KPU  =  KPU  -  1 

IF  (KPU  .EQ.  0)   GO  TO  15 

IF  (LUSH(KPU))   20,12,25 

40  IF  (LUNA(LUSH(KPU-1)+1000»(KPU-1) )  .EQ.  0)   GO  TO  50 
LUSH(KPU)  =  LUSH(KPU)  +  10 
IF  (LUSH(KPU)  .EQ.  0)   GO  TO  12 

50  NAN  =  1 
RETURN 
END 

SUBROUTINE  POP(KPU,KLO) 
COMMON/ LETHE /LI  ST (160,6) , LUSH (250) , NOW (10) »MOON( 150) »KON 

KLO  =  0 
10  KLO  =  KLO  +  1 

NOW(KLO)  =  LUSH(KPU) 
KPU  »  KPU  -  1 
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IF  (LUSH(KPU)  .GE.  1000)   GO  TO  10 
IF  (LUSH(KPU)  .LE.  0)   RETURN 

KPU  =  KPU  +  1 
LUSH(KPU)  =  NOW(l) 

RETURN 

END 

SUBROUTINE  PUSH( KPU»LAG) 

COMMON/LETHE/LI  ST  (160.6)  »LUSH{250)  »NOW(  10)  ♦MOON(150)  .ICON 

COMMON/ I DEM /NAG 

3  LIX  =  LIST(LAG.I) 
KON  =  KON  +  1 
MOON(KON)  =  LAG  +  1000»NA6 

5  DO  10   J«1.LIX 
KPU  «  KPU  +  1 
10  LUSHdCPU)  =  LIST(LAG.J+1) 

IF  (LUSH(KPU-l)  .GE.  1000)   RETURN 

NAG  =  KPU  -  1 
LAG  =  LUSHdCPU-l) 
GO  TO  3 

END 

FUNCTION  LUNA(LNO) 

COMMON/LETHE/LI  ST  (160.6)  .LUSH  (250)  .NOW  (10)  .MOON  (150)  .ICON 
COMMON/INTRY/INS(20C).LIM.IEND»LAB(5).LSI.NEW 
K  *  KON 
DO  10   I  =1.K 
J  =  (KON+D  -  I 

IF  (MOON(J)  .NE.  LNO)   GO  TO  lO 
KON  «=  J  -  1 
LUNA  =  1 
RETURN 
10  CONTINUE 
LUNA  =  0 
RETURN 
END 

FUNCTION  INTAX(MARK.LOVE) 
COMMON/ I DEM /NAG 
COMMON/PATCH/ 1  CON 

COMMON/LETHE/LIST(160,6)  .LUSH(250)  .NOWCIO)  .MOONdSO)  .KON 
COMMON/ INTRY/ INS (200) .LIM. lEND.LAB ( 5 ) .LSI .NEW 
KPU  =  0 
KON  =  0 
NAG  =  KPU 
LEVE  =  LOVE 

10  CALL  PUSH(KPU.LEVE) 
20  CALL  POP(KPU.KLO) 

IF  (NOW(l)  +  1)  70.30.60 

30  MOLD  =  MARK 

31  IF  (MARK  .LE.  LIM)   GO  TO  35 

-  47  - 


c 

c 


c 
c 


c 

c 


c 

c 
c 

c 
c 


IF  (LOOKIN(MARK)  .EO.  -1)   GO  TO  3A 

32  INTAX  =  -1 
RETURN 

34  MOLD  =  MOLD  -  NEW 

35  MFO  =  NOW(KLO) 

IF  (INFUN(MARK»MFO) )   85»45f33 

85  MARK  '    MARK  +  1 
GO  TO  31 

33  KLO  =  KLO  -  1 

IF  (KLO  ,GT.  1)   GO  TO  31 

36  NAY  '^    NAN(KPU) 

IF  (NAY  ,EQ.  0)   GO  TO  40 


37  IF  (MARK  ,LE.  LIM)   GO  TO  137 
IF  (ICON  .NE.  55B)   GO  TO  137 

151  IF  (LUSH(KPU)  .GE»  -1)   GO  TO  154 

152  Ll»SH(KPlJ)  =  0 

IF  (NAN(KPU)  .EO.  0)   40.151 

154  IF  (LUSH(KPU-l)  .GE.  1000)   GO  TO  54 
LEX  "  LUSH(KPU-l) 

LUB  =  LIST(LEX»1) 
DO  155   J=1,LUB 
KPU  »  KPU  +  1 

155  LUSH(KPU)  =  LIST(LEX»J+1) 

IF  (LUSH(KPU)  .LT.  -1)   40»154 

137  IF  (LUSH(KPU-I)  .GE.  1000)   GO  TO  20 
NAG  «  KPU  -  1 
LEVE  »  LUSH(KPU-l) 
GO  TO  10 

40  INTAX  =  1 
RETURN 

45  MARK  =  MOLD 

50  IF  (NOR(KPU)  .EQ.  1)   GO  TO  55 

54  INTAX  =  0 
RETURN 

55  IF  (KPU)   37,40.37 

60  IF  (MARK  .LE.  LIM)   GO  TO  65 

IF  (LOOKIN(MARK)  .NE.  -1)   GO  TO  32 

65  MFO  =  NOW(KLO) 

IF  ( INFUN(MARK.MFO) )   90.66.36 

90  MARK  =  MARK  +  1 
GO  TO  60 

-  48  - 


c 
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66  KLO  =  KLO  -  1 

IF  (KLO  -1)   50»50,60 

70  IF  (MARK  ,LE.  LIM)   GO  TO  80 

IF  (LOOKIN(MARK)  ,F0.  -1)   GO  TO  80 

75  IF  (NAN(KPU)  .EQ.  0)   GO  TO  40 

IF  (LUSH(KPU)  .EQ.  -1)   GO  TO  32 
LUSH(KPU)  =  0 
GO  TO  75 

80  MFO  =  NOW(KLO) 

IF  (INFUN(MARK»MFO))   95.36.81 

95  MARK  =  MARK  +  1 
GO  TO  70 

81  NOW(l)  =  NOWd  )  +  10 
IF  (NOW(l))   36.36»70 


C 

C 


END 

FUNCTION  INREAD(MARK) 

COMHON/INTRY/INS(200).LIMtIEND»LAB(5)»LSI»NEW 

COMMON/PATCH/ 1  CON 

DIMENSION  IBUF( 10)»MM(70) 

IF  (LSI  .NE.  0)   GO  TO  100 

READ (1.1000) (LAB(J)»J=1»5)»LSI.(MM(J)»J»1»66) 

1000  FORMAT (72R1) 
GO  TO  110 
C 

10  INREAD  «  1 
RETURN 
C 

100  IF  (lEND  .EQ.  1)   GO  TO  10 
LITE  =  0 

DECODE ( lO.lOl.KAB)  (LAB(NN) »NN=1.5) 

101  F0RMAT(5R1»5X) 
LSI  =  ICON 
DECODE(70»102»IBUF)  ( MM( NN) »NN=1 »66 ) 

102  F0RMAT(66R1.4X) 
C 

110  READ{1.103)  KAB.IC0N.( IBUF(NN) ♦NN=1»7) 

103  FORMAT(A5.R1»6A10»A6) 

C 

IF  (ENDFIlEI)   130.120 

c 

120  DECODE( 10.104.KAB)   KOM 
lOA  F0RMAT(R1.9X) 

IF  (KOM.EQ.3.0R.KOM,EQ.47.0R.KOM.E0.53B.OR.KOM.EQ.39)   110*25 

C 

130  lEND  =  1 

ICON  «  55B 
C 

25  INREAD  »  0 
C 
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c 
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J  =  67 

30  J  -  J  -  1 

IF  (J  ,E0.  0)   GO  TO  100 

IF  (MM(J)  .EO.  55B)   GO  TO  30 

JP  =  0 
40  JP  =  JP  +  1 

IF  (MM(JP)  .EO.  55B)   60  TO  ^0 
60  NEW  =  J  -  JP  +  1 

IF  ((LIM+NEW)  .GE.  200)   GO  TO  65 

NEW  «  0 

GO  TO  45 

65  LIM  =  LIM  -  NEW 

00  70   IC  =  1.LIM 
70  INS(K)  =  INS(tC+NEW) 

45  MARK  =  LIM  +  1 

DO  50   K  =  JP,J  ■  ' 

LIM  =  LIM  +  1 
50  INS(LIM)  =  MM(K.) 

LO  »  LIM  +  1 
DO  55   LL=L0.200 
55  INS(LL)  »  0 
RETURN 

END 

FUNCTION  LOOKEX(MARIC) 

COMMON/ I NTRY/ INS (200) .L IM t lEND .LAB ( 5 ) .LSI t NEW 
LOOKEX  =  1 

IF  (INREAD(MARK)  ,E0.  1)   RETURN 
IF  (LSI  .EO.  55B)   LOOKEX  =  LOOKEX  -  1 
LOOKEX  «  LOOKEX  -  1 
RETURN 
END 

FUNCTION  LOOKIN(MARK) 

COMMON /I NTRY/ INS (200) .L IM, lEND.LAB ( 5 ) tLSI .NEW 
COMMON /PATCH/ 1  CON 
LOOK  IN  =  1 

IF  (ICON  .EO.  55B)   RETURN 
IF  ( INREAD(MARK)  .EO.  1)   RETURN 
LOOK  IN  =  0 
DO  10   J»l»5 

IF  (LAB(J)  .NE.  55B)   RETURN 
10  CONTINUE 

LOOKIN  =  -1 

RETURN 

END 

FUNCTION  INFUN(MARK.MFU)  SYN 

COMMON/ INTRY/INS( 200) .L I M, lEND.LAB ( 5 ) .LSI tNEW  SYN 

INFUN  =  -1  SYN 

IF  (INS(MARK)  .EQ.  55B)   RETURN  SYN 

MFU  =  MFU  -  1000  SYN 

IF  (MFU  .LE.  100)   GO  TO  100  SYN 

MFU  »  MFU  -  100  SYN 
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GO  TO  ( 10»20f30»40.50) ♦MFU  S.N 

10  INFUN  =  MKMARK)  SYN 

RETURN  SYN 

20  INFUN  =  M2(MARK)  SYN 

RETURN  SYN 

30  INFUN  =  MA(MARK)  SYN 

RETURN  SYN 

40  INFUN  =  M5(MARK)  SYN 

RETURN  SYN 

50  INFUN  =  M8(MARK)  SYN 

RETURN  SYN 

100  INFUN  =  MSPC(MARIC»MFU)  SYN 

RETURN  SYN 

END  SYN 

FUNCTION  MKMARK)  SYN 

COMMON/INTRY/INS(200).LIM,IEND,LAB(5).LSI.NEW  SYN 

Ml  «  0  SYN 

IF  (INS(MARK)  .LT.  33B  .OR,  INS(MAR»C)  .GE.  44B)   RETURN             SYN 

MARK  »  MARK  +  1  SYN 

Ml  =  MARK  SYN 

RETURN  SYN 

END  SYN 

FUNCTION  M2(MARK)  SYN 

COMMON/INTRY/INS(200)»LIM,IEND»LAB(5)»LSI»NEW  SYN 

M2  «  0  SYN 

IF  (INS(MARK)  .LE,  33B  .OR.  INS(MARK)  .GE.  456)   RETURN            SYN 

MARK  =  MARK  +  1  SYN 

M2  ■  MARK  SYN 

RETURN  SYN 

END  SYN 

FUNCTION  M4(MARK)  SYN 

COMMON/INTRY/INS(200)»LIM,IEND»LAB(5).LSI.NEW  SYN 

M4  «  0  SYN 

IF  (INS(MARK)  .LE.  lOB  .OR.  INS(MARK)  .GE.  17B)   RETURN            SYN 

MARK  =  MARK  +  1  SYN 

M4  »  MARK  SYN 

RETURN  SYN 

END  SYN 

FUNCTION  M5(MARK)  SYN 

COMMON/INTRY/INS(200)»LIM.IEND.LAB(5)»LSI.NEW  SYN 

M5  =  0  SYN 

IF  (INS(MARK)  .GT.  lOB  .AND.  INS(MARK)  .LT.  17B)   RETURN  SYN 

IF  {INS<MARK)  .GT.  328)   RETURN  SYN 

MARK  «  MARK  +  1  SYN 

M5  =  MARK  SYN 

RETURN  SYN 

END  SYN 

FUNCTION  M8(MARK)  SYN 

COMMON/INTRy/IN5(200) .LIM, IEND.LAB ( 5 ) t LSI tNEW  SYN 

M8  =  0  SYN 

IF  {INS(MARK)  .LE.  448  .OR.  INS(MARK)  .EQ.  53B)  RETURN             SYN 

MARK  =  MARK  +  1  SYN 

MB  «  MARK  SYN 

RETURN  SYN 

END  SYN 

FUNCTION  MSPC(MARK,MFU)  SYN 

COMMON/ I NTRY/ INS (200) tLIM. lEND .LAB( 5 ) tLSI »NEW  SYN 

MSPC  =  0  SYN 
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IF  (INS(MARK)  .NE.  MFU)   RETURN  i>  .  ,< 

MARK  "  MARK  +  1  SY(*I 

MSPC  «  MARK  SYN 

RETURN  SYN 

END  SYN 

FUNCTION  MEGAL(MOP) 

COMMON/INTRY/INS(200),LlM,IEND»LAB(5)»LSItNEW 

ME6AL  «  0 

K  -  0 

DO  20   J=MOPtLlM 

IF  (INS(J)  .EQ.  55B)   GO  TO  20 

K  «  K  +  1 

IF  (INS(J)  .NE.  54B)   GO  TO  20 

MEGAL  »  K 

RETURN 
20  CONTINUE 

RETURN 

END 

FUNCTION  NOTA( INW.NCH.MARK) 

COMMON/ I NTRY/ INS (200) .LIM* lENO tLAB ( 5 ) tLSI .NEW 

DIMENSION  KWB( 12) 

NOTA  »  0 

NAB  =  MARK 

J  «  0 
10  IF  (INS(NAB)  .EO.  55B)   GO  TO  20 

J  «  J  +  1 

KWB(J)  ■  INSCNAB) 
20  NAB  -  NAB  +  1 

IF  (J  .LT.  NCH)   GO  TO  10 

ENCODE ( 10»200,IDE) (KWB<L) tL^l.J) 
200  FORMAT(lORl) 

IF  (JOE  .NE.  INW)   RETURN 

MARK  »  NAB 

NOTA  «  MARK 

RETURN 

END 

FUNCTION  LABTST(MUMB) 

COMMON/INTRY/INS{200).LIM.IEND.LAB(5)»LSI.NEW 

NU  ■  0 

LABTST  «  0 

MUMB  *    0 

LOW  =  1 

LL  ■  LAB(l) 

IF  (LL.EO.2.OR.LL.EQ.4.OR.LL.EQ.6.0R.LL.EQ.9)   LOW  «  2 

00  10   J-L0W.5 

IF  (LAB(J)  .EO.  55B)   GO  TO  10 

IF  (LAB(J)  .LE.  32B)   RETURN 

IF  (LAB(J)  .GT.  4AB)   RETURN 

NU  -  1 
10  CONTINUE 

LABTST  *    -1 

IF  (NU  .EO.  0)   RETURN 

ENCODE( 10»100»NU)  (LAB( J) ♦J^LOW.S) 

100  F0RMAT(5R1) 

DECODE( 10»101»NU)   MUMB 

101  FORMAT ( 15) 
LABTST  =  1 
RETURN 
END 
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In  this  report  may  not  Infringe  privately 
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method,  or  process  disclosed  In  this 
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with  the  Commission,  or  his  emplojrment  with 
such  contractor. 
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